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ABSTRACT 


This thesis attempts to document the events, 
environment, decisions, and personnel involved in the 
development, implementation and life cycle management of a 
computer software application. The computer application is 
developed using a prototyping methodology and a third 
generation software language for a Department of the Navy 
Headquarters Command. 

The data are presented in a case study format and are 
analyzed in accordance with software life cycle development 
principles and change management principles. The case 
methodology was considered the most applicable tool to 
showcase the complexity of decisions and processes of 
computer systems management. The case studies demonstrate 
the importance of adhering to proven software development 

principles throughout ^he life cycle management of a 

: 

computer application. | /,- 
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I. 


INTRODUCTION 


A. GENERAL DESCRIPTION 

This thesis is an effort to document the events, 
environment and personnel involved in the development, 
implementation and life cycle management of a computer 
software application. Also documented is the maturation 
process of the organization responsible for the computer 
application. The data are presented in the format of six 
case studies which cover a period of two years, and are 
analyzed in accordance with software development life cycle 
management principles and change management principles. 

B. METHODOLOGY 

A case study is a description of a real situation that 
occurred in a real organization [Ref. l:p. 108]. Data 
pertaining to the industry, environment, organization, 
product, and personnel involved in the situation are 
presented. The focus or purpose of a case study is on one 
or several key issues, decisions, or problems requiring a 
solution. The focus of this case study is on decisions 
pertaining to development of computer software and the 
consequences of these decisions on the software and the 
cognizant organizations over a period of time. A case study 
is an effective method for presenting valuable insight into 
the constant technological change and innovation 
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characteristics of the computer systems management field and 
their effects on management and organizational change [kef. 
2:p. 370]. 

The data within a case study are presented not just from 
one person's point of view, but rather by taking into 
account as many different views on a situation as possible. 
Data are presented in chronological sequence and interwoven 
into a narrative format. The narrative format facilitates 
the search for facts, questions, and probable explanations 
for the situation presente by the case. 

The data, covering two years of the life cycle of the 
computer application, we: voluminous. Sources utilized 
were written documentation, interview and direct 
observation. Presentation of the data in a chronological 
sequence was the only way to do justice to the rich 
description of all the factors which played a part in the 
decisions, personnel actions, and the environment of the 
computer application. This methodology also allows for 
presentation of the entire range of details and processes 
surrounding a situation. 

C. BACKGROUND 

The computer application documented is the Officer 
Assignment Information System (OAIS). This application is 
used by Naval Military Personnel Command (NMPC) for 
assignment of Naval Officers. The purpose of OAIS is as a 
tool to facilitate and improve the officer assignment 
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process. OAIS is a menu-driven, online, real-time 
application run on an IBM 4381 mainframe computer. Each 
user has a remote display terminal and keyboard connected 
via a local area network to a mainframe. Personnel 
information, activity billets and automatic orderwriting is 
provided. A batch mode is used for system maintenance, 
updating of files and production of large reports. 

Development of OAIS took place in the early 1980's. A 
prototyping development methodology and a third generation 
software language were chosen for developing OAIS. At this 
time, prototyping was on the leading edge of technology. By 
using prototyping, NMPC hoped that problems concerning cost 
overruns, schedule delays, and applications not meeting user 
requirements, problems which characterized the current state 
of the software development industry, would be avoided. 

D. RESEARCH QUESTIONS 

Two items are of particular interest in this thesis. 

The first question addresses what could have been done to 
alleviate, or prevent, problems encountered with OAIS 
implementation efforts. The second question addresses 
explanations for problems encountered in OAIS implementation 
efforts. The information systems department at NMPC is 
currently preparing for a redesign of OAIS into a database 
system. The command is interested in identification of any 
lessons learned from prior OAIS implementations and any 
possible problems that can be anticipated. Of particular 
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concern for NMPC is identification of any long-term effects 
resulting from implementation of the prototype. 

E. ORGANIZATION OF THESIS 

Following this introductory chapter, the thesis is 
organized into four chapters and two appendixes. Chapter II 
describes the case methodology, its advantages and relevance 
as both a research and teaching strategy. Chapter III 
contains the six case studies documenting the development, 
implementation and life cycle management of OAIS. Chapter 
IV is an analysis of each case study within the case series. 
The analysis is focussed on software development life cycle 
principles and management of change. Chapter V contains 
responses, conclusions, and recoirunendations in accordance 
with the stated research questions. Appendix A contains a 
description of OAIS software interfaces with other computer 
applications. Appendix B contains timelines and lists of 
personnel. The timelines document significant events during 
OAIS development and implementation. This documentation can 
be of assistance to both case study students and 
instructors, enabling them to follow the flow of events and 
personnel over time. 
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IT. 


CASE .-:feTHODOLOGY 


A. INTRODUCTION 

This chcipter addresses the case methodology. The 
advantages and drawbacks of a case study in comparison with 
other research methods are cisc-ssed. The use and benefits 
of a case study for both research and teaching purposes also 
are explored. 

B. CASE STUDY FOR RESEARCH PURPOSES 

A definition of a case study for research purposes is as 
follows: 

A case study is an empirical inquiry that 

investigates a contemporc.ry phenomenon within its 
real life context; when 

the boundaries between phenomenon and context are not 
clearly evident; and 

multiple sources of evidence are used. [Ref. 3:p. 

23] 

In this definition, case study research stands on its 
own as a research strategy. Prior to this definition, a 
common misconception held by those uneducated in case 
methodology was that research strategies were of a 
hierarchial nature [Ref. 3:p. 15]. Case studies were 
considered as being at the bottom part of the hierarchy. 
Their use was for the most part a preliminary to other types 
of research. Consequently, case study usage was primarily 
limited to the exploratory stage of research. Also case 
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studies were viewed as consisting of only one small part of 
the above definition, that of investigating a contemporary 
phenomenon within its real life context. This is evident 
when case studies are just used to analy^e decisions, 
processes or events. [Ref. 3:p. 23] 

Views on conducting research have evolved to a point 
that each different type of research strategy is viewed as 
"a different way of collecting and analyzing empirical 
evidence." [Ref. 3:p. 15] These views have evolved from 
the narrow niche given to case studies and the wide, 
prescriptive view given to experiments. Recognition of the 
best type of research strategy is now based on subject 
matter and research purposes. Researchers in a 
"traditional" sense, where emphasis is on quantitative, 
controlled events and results that are generalizable and 
replicable have recognized the benefits derivable from case 
research. Each type of research strategy can be used for 
each of the three different purposes of research; 
exploratory, descriptive or explanatory. Which strategy is 
used depends on the following three conditions: (1) type of 
research question; (2) extent of control over behavioral 
events; (3) focus on contemporary or historical events [Ref. 
3:p. 16]. 

The five recognized research strategies within the 
social sciences are experiment, survey, archival analysis, 
history and case study. Experiments, history and case 
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studies are research strategies that apply to a "how" or 
"why" type of researr-h question. Experiments focus on 
contemporary phenomena, but require control over behavioral 
events. History does not focus on contemporary phenomena 
and also does not require control over behavioral events. 

As previously defined, a case study focuses on contemporary 
phenomena in which there is no control over behavioral 
events. The only difference between history and case study 
research strategies, besides the focus of the research, past 
versus present, is that case study researchers have an 
advantage of adding direct observation and interviews to 
their research methodology. [Ref. 3:p. 19] 

C. ADVANTAGES OF CASE STUDIES 

"As a research endeavor, the case study contributes 
uniquely to our knowledge of individual, organizational, 
social and political phenomena." [Ref. 3:p. 14] New 
situations, interactions and problems occur every day. Case 
studies provide for a description of "holistic and 
meaningful characteristics of such real life events as 
individual life cycles, organization and managerial 
processes, neighborhood change, international relations, and 
maturation of industries." [Ref. 3:p. 14] 

A unique strength of case study research is its ability 
to utilize multiple sources of evidence in presenting data 
[Ref. 3:p. 20]. Such evidence includes documents, 
artifacts, interviews and observations. This characteristic 
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enables presentation of data from all points of view and 
perception. Rarely does one view of a situation contain all 
the pertinent facts contributing to a situation. By having 
access to multiple sources of evidence, the full story or 
explanation is easier to piece together. Case study 
research allows a showcasing of cause and effect factors of 
a situation or problem. With the active observation of a 
case study researcher, many details are provided in addition 
to available written docu.aentation. This facilitates an 
ability to document the pc 'ible causes and effects in a 
relationship. 

Another advantage to ^e case study method can be found 
in the use of qualitative data. Qualitative data is in the 
form of words, not the numbers traditionally relied on. 
Qualitative data does have some advantages over quantitative 
data. Qualitative data are a "source of well-grounded, rich 
descriptions and explanations of processes occurring in 
local contexts." [Ref. 4:p. 15] Words gleamed from 
interviews, observations and documentation can indicate 
people's attitudes, internal relations among personnel and 
relative power and influence within an organization [Ref. 
5:p. 49]. Words possess a quality of "undeniability" about 
them [Ref. 4:p. 15]. "Words, organized into incidents/ 
stories provide a concrete, vivid, meaningful flavor that 
often proves far more convincing to a reader...than a page 
of numbers." [Ref. 4:p. 15] 
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D. DISADVANTAGES OF CASE STUDIES 

A major difficulty contributing to acceptance of the 
case study as a significant research strategy is that the 
data gathered and analyzed are qualitative in nature. 
"Numbers don't lie" is a popular cliche in support of 
quantitative data. This negative viewpoint is based 
primarily on two factors. One factor is that words can have 
a variety of meanings. The interpretation given to them by 
the researcher is viewed as a possibility for bias. The 
numbers faction prefers experiments where there is control 
over events and the results, in the form of numbers, are 
interpreted the same by all analysts. There can be no bias 
in the interpretation of numbers. Secondly, there is a 
preference for being able to control events which brings up 
the question of replicability. Would another person viewing 
the qualitative data of a case study come up with the same 
conclusions? Would another researcher be able to replicate 
the entire case study from data gathering through analysis? 
"Observations tend to be unique and non-replicable." [Ref. 
6:p. 2] The question concerning the replicability of a case 
study adds a degree of uncertainty to the research process 
[Ref. 4:p. 16]. 

Additional uncertainty also comes from lack of detail in 
the documentation that case study researchers provide on 
their methodology. Some past case study results have been 
found to be influenced/ biased by the researcher. A 
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contributing factor to this lack of documentation is the 
lack of accepted and standardized methods for qualitative 
data analysis, and a lack of a common language. [Ref. 4:p. 
16] 

There are several other drawbacks to the case 
methodology. The preparation of case studies is time- 
consuming and their documentation is voluminous. The fact 
that there is little basis for scientific generalization is 
also considered a major stumbling block [Ref. 3:p. 20]. A 
typical skeptic of case study research, who is immersed in 
the quantitative viewpoint, looks to conclusions of the 
research to be generalizable to other situations. This is 
not the intent of case study conclusions. "Case study 
conclusions are generalizable to theoretical propositions 
and not to populations or universes." [Ref. 3:p. 21] They 
are not even generalizable to other organizations. "In this 
sense a case study does not represent a 'sample' and the 
investigators' goal is to expand and generalize theories 
(analytic generalization) and not to enumerate frequencies 
(statistical generalization)." [Ref. 3:p. 21] 

An example of a case study giving emphasis to a 
theoretical concept is as follows: the Cuban Missile 
Crisis. This exact situation will never happen again, but 
there are general lessons that can be learned. These 
lessons include "the management of the problem, and the role 
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of organizational routine in shaping events and decisions." 
[Ref. 7:p. 295] 

The case study as a research strategy has been used in 
many different areas: 

policy, political science, and public administration 
research; 

community psychology and sociology; 
organizational and management studies; 

city and regional planning research, such as studies of 
plans, neighborhoods or public agencies,.... [Ref. 

3:p. 16]. 

The use of case study research has also proven valuable 
to the information systems area. "The information systems 
area is characterized by constant technological change and 
innovation." [Ref. 2;p. 370] This change and innovation 
has an impact on management and organizational issues in an 
information systems department. Case study research has 
been able to provide valuable insights into these issues 
[Ref. 2:p. 370]. 

E. CASE STUDIES FOR TEACHING PURPOSES 

According to Dorothy Robyn, "there are two criteria 
potentially present in any learning situation." [Ref. 8:p. 
1] These two criteria are the content or specific knowledge 
to be learned and the learning process. The learning 
process concerns itself with presenting a general approach 
or methodology to problem solving and decision making. A 
student's knowledge and ability to deal with the reality of 








life outside the classroom is dependent on both of these 
criteria. [Ref. 8:p. 1] 

Case studies basically follow the principle of "learning 
by doing." Case studies present real life with all of its 
associated complexity. Experience with case studies 
provides stud<=nts with exposure to a wide range of real life 
situations which could take a lifetime to experience 
personally. This experience offers a basis for comparison 
should the student run into the same situation outside the 
classroom [Ref. 9:p. 56]. 

For the most part, a classroom setting presents facts 
and situations which have only one right answer [Ref. 8:p. 
2]. A student in a lecture/classroom environment is a 
receiver of facts [Ref. 9:p. 56]. Real life deals with 
situations in which not all the relevant facts of a decision 
are available or in which a decision is not straightforward 
in that there is no right solution. "Case studies are 
valuable lessons in teaching students the habits of 
diagnosing problems, analyzing and evaluating alternatives 
and foirmulating workable plans of action." [Ref. 9:p. 56] 
Additionally, students must learn that decisions are not 
just made from an analysis of the facts. "The decision is a 
political process... involving power and influence." [Ref. 

6:p. 2] 

Using case studies in learning situations provides a 
student with an opportunity to apply theory to a situation 
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within the safety of a classroom environment. In essence a 
case study is a "simulated experience." [Ref. l:p. 109] An 
additional benefit is an ability to apply known theory to 
contemporary happenings to see if a theory holds true. If 
it doesn't, there is opportunity to search for reasons for a 
cause and effect. Debates between students over a cause, 
effect and solution to case study problems provides the 
benefits of requiring them to question their assumptions and 
to defend their positions on issues. Other benefits of the 
use of a case study in a classroom include teaching students 
the following skills: how to search for facts, choose 
between alternatives, and what questions it is essential to 
ask. [Ref. 8:p. 2] 

Retired Navy Admiral Stansfield Turner believes strongly 
in utilization of case studies in a military classroom. He 
says, "Many of the education programs, are simply cramming 
officers' heads with facts rather than helping them to 
develop the skills to deal with difficult problems of 
leadership, strategy and management." [Ref. 10:p. 1] 

Admiral Turner feels that using the case study method "will 
help prepare students for the time when they rise to the 
level where they really have to make decisions for our 
country." [Ref. 10:p. 1] 

F. METHODOLOGY OF THESIS CASE STUDY 

The case study series that is the subject of this thesis 
concerns the chronological events of an organization during 
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a period of two years. The case series describes the 

maturing of an automated data processing division and its 

interactions with other departments of the organization in a 

Department of the Navy Headquarters Command. An 

organizational case study is defined, 

...where you purposely observe the entire configuration of 
individuals and groups in the setting of an organization, 
...and you observe events in the way that they naturally 
unfold, without imposing any sort of experimental controls 
or treatments whatsoever on what it is you're observing." 
[Ref. 6:p. 1] 

It is typical of organizational case studies to refer to 
the private mental state of individuals, to the privately 
held meanings that the s grounding organization has for 
them and to features of tne underlying social structure 
none of which can be seen directly. [Ref. 6:p. 2] 

A case study "treats people as the observable agents through 

which the unobservable forces of the organization act." 

[Ref. 6;p. 9] 

The case study writer was a member of the automated data 
processing d ivision and a primary participant in the day-to- 
day events that have been documented. There does exist the 
possibility for bias in the writing of this case study, but 
a conscious effort was made to avoid any potential for bias. 
For example, observation consisted of memory recall by the 
case writer and verification of observations by several of 
the interviewees. 

The setting of the case study is a contemporary 
situation in that computers and computer systems management 
is a relatively new field within the past two decades. Of 
particular importance in this case study is the use of a 
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prototyping methodology for the development of the computer 
application and the use of a third generation software 
language. The evolution of a computer application over a 
two-year time period and the maturing of the organization 
responsible for its development in terms of organizational 
structure, policies and personnel are described. Sources of 
evidence included written documentation, interview and 
direct observation. The written documentation included user 
and system documentation on the application, and reports on 
the development of the application by contractor and in- 
house personnel. Interviews were conducted primarily over 
the phone with a total of 11 out of 15 of the principal 
players within the organization. Personnel interviewed 
covered the entire hierarchy of management, contractors, 
project officer, front line supervisors and worker 
personnel. A major caveat is that a few of the interviewees 
are still attached to the organization. Some of their input 
may have been tempered by still being involved with the 
computer application. The data presented by these 
interviewees may be shaded towards protecting the 
organization. 






III. CASE STUDIES 


A. INTRODUCTION 

A series of six case studies is presented in this 
chapter. The primary theme in the case series is the 
development and life cycle management of the Officer 
Assignment Information System (OAIS). A secondary theme is 
the maturing of an automated data processing organization. 
Case study one contains the background events of OAIS 
development. It describes the implementation of the OAIS 
prototype and covers the timeframe of November 1982 through 
October 1985. Case study two presents the events preceding 
the implementation of the first major change to OAIS. These 
changes are a software conversion and an enhanced order¬ 
writing module. The time period covered is October 1985 
through May 1986. Case study three concerns the failure of 
the new version of OAIS. Command, user and project officer 
reactions to the failure are addressed. Case study four 
presents the events leading up to a second try at 
implementation of a new version of OAIS. Also, during this 
time period of May 1986 through May 1987, the organization 
responsible for OAIS development is transitioning from one 
with an emphasis on development to one where production 
issues are of equal importance. Case study five describes 
the problems with the second implementation of the new 
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version of OAIS. Case study six describes the 
organization's recovery from the problems generated from the 
OAIS implementation and changes made to deal with present 
and future computer systems management. 

Organization charts, where applicable, are contained 
within the body of the case studies. Appendix A contains a 
description of OAIS interfaces. Appendix B contains 
timelines and lists of NMPC-47 personnel for case studies 
two, four and six. These timelines document important OAIS 
and NMPC-47 events over time. This documentation can be 
used to clarify the case studies and be used in conjunction 
with the teaching notes contained in Chapter IV. 

B. CASE STUDY ONE 
1. Background 

OAIS (Officer Assignment Information System) is the 
first in a planned series of four applications which combine 
to form the Naval Military Personnel Distribution System 
(NMPDS). NMPDS was designed to support the Distribution 
Division (NMPC-4) of the Naval Military Personnel Command 
(NMPC). The mission of NMPC-4 is to assign officer and 
enlisted active duty personnel in accordance with the needs 
of both the Navy and the individual's career, and to control 
the manning of activities as specified by the Chief of Naval 
Operations. The goal of the NMPC-4 mission is to "Put the 
right person in the right job at the right time." 
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2 . 


Development and production of NMPDS are the 
responsibility of NMPC-47, the Distribution Support 
Department. As of October 1985, NMPC-47 was organized as 
per Figure 1. The Information Systems Development branch, 
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Figure 1. NMPC-47 Organization, October 1985 
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N470, was responsible for all development and production 
decisions concerning OAIS, On-line Distribution Infomnation 
System (GDIS) and other systems which fell under the 
umbrella of NMPDS. The data administration function, 
training function, Application Programming Shop and 
Information Center made up the rest of N470. The 
Information Systems Support branch, N471, included Officer 
and Enlisted Error Research (help desk), Systems 
Administration (network hardware and software), Scheduling, 
and Configuration Management. The Order Support branch, 
N472, consisted of orderwriting experts and order 
distribution. Scheduling was responsible for running 
backups, batch updates, and daily, weekly and monthly OAIS 
reports. These reports were distributed by the Order 
Support branch, N472, to assignment and placement officers. 

3. Background of NMPDS 

NMPDS was designed to be a tool to help optimize 
unit manning, minimize personnel turbulence, minimize 
assignment costs, enhance individual career development, 
improve personalized service to constituents, and maintain 
accurate and timely personnel and distribution information. 

Applicatic ithin NMPDS were planned to have the 
following charac+'eristics: 
terminal driven. 

interactive data entry and transaction oriented, 
on-line information retrieval. 
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distributed processing oriented to functional user. 

single point of data entry. 

standardized processes. 

central control of data, resources and 
telecommunications. 

modular structure for expandability and flexibility. 

Two major guidelines, top management commitment and 
involving the user in all phases of development were agreed 
upon during the planning stages of NMPDS and would apply 
throughout the NMPDS lifecycle. 

4. Officer Assignment nformation System fOAIS) 

OAIS automated the distribution process involved in 
assignment of officers tc illets. OAIS was designed as a 
tool to facilitate and improve the assignment process by 
providing access to all officer distribution files through 
one computer application. The application provides 
information to both assignment officers (detailers) and 
placement officers. 

The Officer Assignment Information System (OAIS) is 
a menu-driven, on-line, real-time application run on an IBM 
4381 mainframe computer. Each user has a remote display 
terminal and keyboard connected via a local area network to 
a mainframe. By accessing either the Assignment Officer 
Menu or Placement Officer Menu, personnel information, 
activity billets and automatic orderwriting are provided. A 
report menu is available for generation of specific reports 
desired by users. A batch mode is used for system 
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maintenance, updating of files and production of large 
reports. 

The manual steps involved with orderwriting were 
automated by OAIS. Before OAIS, orders typically took four 
to five weeks to get through the chop chain once an officer- 
assignment match was made. After OAIS, orders could be 
generated and sent within trfo to three days. 

Information provided by OAIS falls into three main 
categories: personnel, activity and billet. Personnel 

information provided by OAIS includes: biographical, 
performance evaluation, duty preferences, and career 
history. Activity information provided is organization, 
administrative and mission specific. Billet information 
includes: billet titles, designators, subspeciality codes 

and manning requirements. 

The network operating system for the IBM 4381 
mainframe is IBM's MVS with CICS as the basic communications 
software in the multi-user environment. Communication 
between terminals, printers, and the IBM 4381 mainframe was 
conducted through the use of a bus local area network. The 
local area network and its associated bus interface units 
were owned by NMPC-16. Bus interface units are hardware and 
contain eight available ports for access onto the network. 
Bus interface units allowed flexibility in location and 
subsequent moving of OAIS terminals within an office space. 
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5. Users of OATS 


An assignment officer is responsible for the 
personal and professional interests of individual officers 
and assists them in pursuing their career. Placement 
officers ensure that each Naval activity is optimally manned 
with the best qualified officers. The job of being an 
assignment officer or placement officer included a lot of 
stress. There were pressures from senior officers to 
conserve money and pressures from activities to get the best 
officers for their command. Assignment officers spent most 
of their days on the phone talking to constituents about 
upcoming orders or counseling on career moves. A typical 
assignment or placement officer was a Lieutenant Commander 
or Commander. Often times they came from leadership 
positions of executive officer equivalence. They were used 
to having many people working for them. As an assignment or 
placement officer they were on their own with a constantly 
ringing phone and a computer application called OAIS. 

Quick identification of personnel and billets coming 
up for reassignment are available with OAIS. The major 
piece of information that drives the reassignment 
(availability) process is the Projected Rotation Date (PRD). 

Every active duty officer has a PRD assigned upon 
arrival at a new duty station. Depending on location and 
type of job, this PRD ranges from 12 to 36 months. The 
assignment officer will begin looking for billets for 
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personnel with PRD's six to nine months in the future. The 
placement officer is also looking at filling the billets 
made vacant on PRD's and advertises billets that will be 
coming available. Once the best officer-billet match has 
been determined by the assignment officer, OAIS facilitates 
the officer-billet match approval process and orderwriting 
process. The approval process consists of an automated chop 
chain which routes the proposed officer-billet natch through 
the appropriate personnel. The automated chop chain 
facilitates expediency and communication between the 
assignment and placemaiit officers. The orderwriting process 
includes decisions on training (what, where, how long) and 
costing of orders. The information necessary for this 
portion of the process was automated, replacing paper charts 
and schedules. 

Improvements were made by OAIS in three categories: 
data accuracy, naval resource utilization and officer 
morale. Improved data accuracy resulted from automation of 
previously manually maintained distribution information. 
Improved naval resource utilization resulted from having 
billet assignments made from a larger pool of candidates, 
decreased incidence of inaccurate reporting instructions on 
PCS moves and misassignments. Improved officer morale 
resulted primarily from a reduction in the amount of time 
required for the assignment process. 
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6. Software Development 


OAIS software was developed using a prototype 
methodology and a language called Application Productivity 
Systems (APS)COBOL. APSCOBOL was developed by SAGE Federal 
Systems. It is a third generation software language 
designed to produce COBOL code very quickly. Application 
generators are used to produce source code from high level 
specifications, reduce programming of certain system 
functions and enable junior programmers to produce 
sophisticated code with little training. Additional 
benefits of APSCOBOL were its advertised transportability 
between various types of hardware and its upwardly 
compatible design. Other software tools used during 
development were screen painters which assisted in 
configuration of data entry screens and report generators 
which facilitated access to specific data from files for 
generating reports. 

The current instructions regarding development of 
information systems did not include prototyping as a 
methodology. Events which took place during OAIS 
development were matched as closely as possible with the 
Life Cycle Management Milestones which was directed under 
current software development instructions. 

When the OAIS project was first established, the 
hardware on which the application operated was leased. This 
decision was due to a necessity of proving the quality and 
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efficiency of OAIS and subsequently NMPDS before additional 
resources were expended. Also, the procurement process for 
the hardware was not completed and management was not sure 
exactly what type of hardware would be contained in the 
final contract. 

The benefit of an upwardly compatible design was 
that in subsequent revisions to the software code, only 
minor changes would be required to change over to a new 
version. The compatibility feature was part of SAGE's 
design architecture. 

The initial version of APSCOBOL was JK, with the 
next version called one point seven (1.7). When NMPC 
procured APSCOBOL, it was not yet available commercially. 
NMPC was able to get a good deal on the price and be on the 
leading edge of technology. A prototype approach was used 
for a variety of reasons. One was the necessity of 
automating the assignment process as quickly as possible. A 
study group had been studying the assignment process problem 
since 1978. A prototype approach also would assist in 
determining just what OAIS was to do by giving users a 
concrete example to illustrate their ideas and requirements 
on. The original version of OAIS was just automation of the 
manual officer assignment process for the Surface 
Distribution Department. 
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7. Implementation of OATS 


Development and implementation of OAIS was done in a 
modular fashion. In November 1982, the Surface detailers 
(NMPC-41) were used to test and modify the pilot prototype. 
When time came to take the tested and approved prototype and 
complete the design and development process, the Surface 
detailers had become so dependent on OAIS that the decision 
was made by NMPC-47 to implement the prototype. Over the 
next 18 months the other officer oriented departments of the 
Distribution Division were brought on-line. See Figure 2. 
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Figure 2. NMPC-4 Organization 
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Implementation of OAIS throughout the Distribution 
Division was done in a modular fashion for a variety of 
reasons. Among these were the original strategic plan of 
development and implementation in a modular fashion, 
problems with hardware acquisition and the need for minor 
modification cf OAIS to accommodate each different 
department. A prime 750 mainframe computer, which is non- 
IBM compatible, was initially leased to run OAIS. Next, an 
IBM 4341 was leased until inhouse hardware was procured. 
During this period, 1982-1985, the scope and capabilities of 
OAIS could not be expanded to satisfy more users. 

Assignment and placement officers' way of doing 
business was drastically changed by OAIS. Terminals 
replaced paper passed from desk to desk. Secretarial jobs 
changed from being purely clerical to a required interaction 
with a computer and computer-driven reports and processes. 
Even though OAIS was available on every desk, many personnel 
did not initially use the computer application. Reasons for 
non-use by the assignment and placement officers ranged from 
being afraid of the computer, to already using another 
personally-owned computer system, to being stuck in the old 
ways of having their secretaries do the clerical work on the 
computer while they planned in a manual mode. The Medical 
Department, within NMPC-44, was one of the divisions using 
personally-owned computers. They had set up files on their 
constituents using a database system. This system worked 
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fine until the assignment officers transferred and took 
their computers with them. Mrs. Clancey, a secretary in 
NMPC-44, refused to turn on the computer. She continued to 
use her manual methods. 

In the Submarine Department, OAIS was utilized far 
more than in other recently implemented departments. This 
was due to the top management commitment of the Submarine 
Department. These personnel came from a technical 
background and did not fear the computer coming into their 
workplace. Due to their bosses' support of OAIS, all the 
personnel within the department were soon proficient on 
OAIS. 

Placement officers were one of the last groups of 
users to climb onboard the OAIS bandwagon. Before OAIS, 
placement officers maintained their personnel lists on a 
manual slate with a strip of paper for each officer in each 
billet at an activity. In one glance they could determine a 
status of their billets at any activity With OAIS being 
constrained by the number of lines per screen, an entire 
activity could not fit onto one screen. In the eyes of a 
placement officer, this was a major drawback to the 
application. Until the orderwriting process was automated 
in 1985, there was really no benefit to them to using OAIS. 

8. User Representatives 

Each officer distribution department was represented 
by a user representative, selected by the department head. 
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This user representative was supposed to be experienced with 
OAIS usage and functions. The responsibilities of user 
representatives included attendance at OAIS user meetings, 
reporting back to their department issues of the OAIS user 
meetings, and bringing problems of the department to the 
meeting. Also, any suggested enhancements to OAIS from 
individual departments were to be routed to their respective 
user representative for review. It was the responsibility 
of a user representative to pass OAIS information around the 
department, so that each individual OAIS user was not 
calling the help desk. 

9. Training 

The importance of training was discovered in 
parallel with the expansion of OAIS users to the Submarine 
and Aviation communities. Training had not been a problem 
with the Surface Department due to their daily involvemen'" 
with development. Their sense of ownership of OAIS promoted 
self-training. CDR Hazel was brought on-board in July 1984 
to be the Training Officer and to design a training program 
and OAIS User Manual. CDR Hazel became the resident 
functional expert on OAIS and on the specific needs of 
assignment and placement officers. The Training Development 
Project was established. A contract was arranged with Oak 
Ridge Associated Universities in Oak Ridge, Tennessee, to 
develop computer-aided training. This training would serve 
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OAIS, and ODIS users, who were figured to number in the 
hundreds. 

10. Documentation 

Due to budget constraints, the push for software 
development and implementation of the prototype, there was a 
significant lack of operational and requirements 
documentation on OAIS. Original documentation provided by 
the contractor was of poor quality. There were no detailed 
requirements documents. The majority of the documentation 
was contained within the comment portion of the code. The 
first user's manual was published in January 1985. Planning 
documents included functional descriptions for OAIS and 
NMPDS, operational requirements for OAIS, system 
specifications for OAIS, conceptual design for OAIS, program 
specifications OAIS and data base specifications for NMPDS. 

C. CASE STUDY TWO 
1. Background 

The Officer Assignment Information System (OAIS) 
which is used by the assignment and placement officers at 
Naval Military Personnel Command has been operational for 
three years. The organization responsible for OAIS is on 
the brink of many changes; personnel, software and hard¬ 
ware. The personnel responsible for planning and bringing 
the OAIS concept to reality in NMPC-47 and at the contractor 
are leaving. A new project officer is taking over at a time 
when the first major software change to OAIS is in progress. 
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The first of four IBM mainframe computers, an IBM 4381, has 
been delivered after an exceedingly long procurement period. 

2. New OAIS Project Officer. October 1985 

LT Hopkins arrived at NMPC to be the OAIS Project 
Officer. She had just graduated from the Naval Postgraduate 
School with a Master's Degree in Computer Systems 
Management. She relieved CDR Zeke who was the initial 
project officer for the OAIS project. CDR Zeke had been 
responsible for the growth and maturation of OAIS. He had 
seen it grow from a fledgling system with 50 users in 1982 
to a powerful system upon which NMPC assignment and 
placement officers were now heavily dependent. OAIS users 
numbered approximately 300, 

The mindset of the project officers when LT Hopkins 
arrived concerning the contractor, SAGE, was, "We are paying 
big bucks for a quality product." The contractors were 
taken at their word concerning all aspects of system 
development and production and they had been proven correct 
in the past. 

The contracting and budget portions of the job were 
a particular difficulty for LT Hopkins. The primary 
contractor for OAIS was Oak Ridge National Laboratory 
(ORNL), a division of the Department of Energy. The 
contract with ORNL was a research and development contract. 
There was not much substance nor specifically spelled out 
deliverables. The emphasis was on the research and 
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development of the prototyping methodology. SAGE were sub¬ 
contractors of ORNL. In order to get contracting changes 
through to ORNL, approval was required by the Total Force 
Automated Systems Department (NMPC-16). NMPC-16 was 
responsible for all automated data processing programs and 
related support. Since OAIS was now three years old, they 
viewed contracting charges in terms of maintenance and as 
they conformed with the Life Cycle Milestone methodology. 

3. Personnel 

The majority of 0/history and expertise existed 
in the brains of CDR Zeke and the project manager at SAGE. 
When the poor quality dor ’mentation was delivered by SAGE, 
CDR Zeke said, "Don't worry about it, we know what we are 
doing." When LT Hopkins relieved CDR Zeke, the project 
manager at SAGE transferred to another project. The 
personnel left within NMPC-47, familiar with OAIS history 
and its evolution were Mr. Smith, the Technical Director and 
the two branch heads, CDR Rice and CDR Cinder. CDR Rice and 
CDR Cinder had been on-board less than a year. 

Besides CDR Zeke, the other major player in the 
evolution of OAIS was CAPT Dennis. CAPT Dennis had been the 
NMPC-47 Department Head from 1983 to August 1985. CAPT 
Williams had just recently relieved him. 

CDR Hazel, the current Training Officer, was offered 
the job of OAIS Project Officer before LT Hopkins reported 
aboard. He turned it down as it was described as a 
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caretaker job and CDR Hazel always enjoyed a challenge. LT 
Hopkins was informed of CDR Hazel's expertise by CDR Zeke 
and he recommended that she utilize CDR Hazel's knowledge. 

LT Hopkins kept to herself and did not try and make 
the acquaintance of her fellow officers within the 
department. 

LT Perkins reported on-board in December 1985. She 
was designated as the replacement for CDR Hazel, who was 
moving up to be the Order Support branch head. CDR Hazel 
left LT Perkins alone with OAIS for two weeks while on 
vacation. With his assistance on orderwriting procedures, 

LT Peikins became a functional OAIS expert second only to 
CDR Hazel. CDR Hazel and LT Perkins became good friends. 

CDR Griffin reported on-board in April 1986. He had 
just graduated from the Naval Postgraduate School and was to 
be the branch head of Information Systems Support. See 
Figure 3. 

4. NMPC-47 Organization 

CDR Rice and CDR Cinder had worked out an informal 
matrix management plan for accomplishment of OAIS taskings 
within NMPC-47. Programming expertise existed and was being 
nurtured in the Application Programming Shop of the 
Information Systems Development branch. The original plans 
for OAIS called for SAGE to create the first version of OAIS 
and for the Navy to take over maintenance of the project 
afterwards. Towards this end, the Application Programming 


33 









NMPC - 47 

May 1906 



Figure 3. NMPC-47 Organization, May 1986 


Shop was being expanded by adding experienced Data 
Processing Technicians (DP's). Expertise on the external 
programs with which OAIS interfaced, existed in the 
Information Systems Support branch, N471, in the Officer 
Error Research section. Officer Error Research also handled 
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users' problems concerning AUTONOM rejects and tracking the 
status of officer orders. Hardware and systems software 
expertise was also contained within the Information Systems 
Support branch, in the Systems Administration section. 

When LT Hopkins needed assistance or technical 
advice, she went to the experts within the matrix. Quite 
often, personnel in the Information Systems Support branch 
were tasked by LT Hopkins without their supervisors being 
airfare of it. LT Hopkins was under pressure and her approach 
to her problems was blunt and aggressive. She would 
approach enlisted personnel and fellow officers with, "I 
want this done now." 

Personnel in the Information Systems Support branch, 
N471, were not included at NMPDS planning meetings. Though 
N471 personnel kept the current systems going from day to 
day, any problems encountered were considered status quo. 
They were told by CDR Cinder that OAIS would solve all of 
their problems. Focus was on development and the future. 
Towards this end, CDR Rice and CDR Cinder had developed 
extensive integration plans. Having the Order Production 
Module (0PM) would enable the combination of officer and 
enlisted order generation. They envisioned the combination 
of the Officer and Enlisted Error Research Sections. 

LT Smith, in charge of the error research divisions, 
felt a lack of connection between reality and the 
integration plans. She convinced CDR Cinder to hold off on 
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the integration plans for the error research division due to 
the vast differences between the officer and enlisted 
programs through which OAIS and EAIS interfaced. 

LT Smith was not invited to attend OAIS User 
Representative meetings either. Though her personnel were 
tasked by LT Hopkins and were responsible for answering 
error research questions and investigating AUTONOM rejects, 
she was not included. However, she attended as many 
meetings as possible. 

5. Trainj na 

LT Perkins was not as busy as she was used to, 
having just come from an officer-in-charge billet. A new 
list of users was provided by Configuration Management on a 
weekly basis to LT Perkins. LT Perkins would visit the 
personnel individually and offer them training. Training 
consisted of hands-on training for OAIS and ODIS. In some 
divisions, the OMS user representative would set up 
training for their new personnel, knowing the full value of 
training by LT Perkins. In other divisions new users 
decided they did not have time for training in the short 
turnover period. 

LT Perkins felt left out of the main stream of 
activities. There were no professional nor friendly 
overtures from personnel within the OAIS project through 
which she would naturally have interfaced. 
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6 . 


When LT Hopkins took over, plans were already 
underway at the contractors for a conversion of the software 
version of OAIS. The first version of APSCOBOL was JK and 
it was developed in 1981. Since that time, SAGE had 
discovered quite a few problems with the code and wanted to 
enhance their product. SAGE announced that they were 
discontinuing support for the JK version. 

In addition to the software conversion, the 
orderwriting portion of OAIS was redesigned. The current 
orderwriting procedures were just an automated version of 
the manual method. With the advent of automation and the 
input of several serious users, shortcuts and enhancements 
were needed and desired to the orderwriting process. Also, 
it was planned that the Order Production Module would take 
the place of AUTONOM. The Order Production Module would be 
the responsibility of NMPC-47, in addition to supporting an 
increased variety of order formats as compared to AUTONOM 
capabilities. Over the three years of OAIS production, 
reliance on AUTONOM without a fommal level of service 
agreement with NMPC-16 had been a cause of many problems 
concerning late or missing updates and production of hard 
copy orders. 

7. Navy Programming Responsibilities 

The job of writing the new orderwriting procedures 
was given to the Application Programming Shop. This shop 
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consisted mostly of programming experienced. Data Processing 
Technicians (DP). The DP in charge was DPI Brown. DPI 
Brown took the responsibility for rewriting the orderwriting 
procedures. He and a few DP's worked relatively on their 
own at NMPC. 

The contractors were responsible for conversion of 
the existing OAIS code, both batch and online, and the 
correction of several trouble reports. The grand plan was 
that the DP's and the concractors would work closely 
together, so that the DP's, could become more familiar with 
OAIS programs which they were due to take over after this 
conversion effort. Some ^ DP's and systems administration 
personnel worked with the contractors at their site in 
Rockville, Maryland and assisted with the conversion. 

There was little coordination between DPI Brown and 
the personnel at SAGE prior to implementation. Also, a late 
decision was made concerning the 0PM. It was determined 
that it would not be ready in time for a May implementation, 
so the new version of OAIS had to be jury-rigged to 
interface with AUTONOM. Bits and pieces of the new software 
were tested separately, but there was not a complete test of 
the OAIS application nor a systems stress test to check the 
performance of the hardware with the new version of 
APSCOBOL. 

LT Hopkins asked questions about testing procedures, 
but was inexperienced and really did not know the right 
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questions to ask. Also, at this time there was no separate 
test vehicle available for testing. The testing that was 
done was done on a timesharing basis, with batch production 
jobs, in the evening hours. 

8. Preparation for Mav 1986 Implementation 

In preparation for the new version of OAIS set to 
come on-line in May 1986, LT PerKins updated the 
orderwriting procedures for inclusion in the OAIS User 
Manual. In April, CDR Hazel and LT Perkins arranged 
training sessions with the OAIS users in a conference room 
to review changes to OAIS and to distribute the updated OAIS 
User Manual. 

On the first day of production for the new version 
of OAIS, LT Hopkins waited impatiently in her office to hear 
how OAIS was doing. This was her first time managing a 
computer software project as well as being her first major 
accomplishment at the command. 

D. CASE STUDY THREE 
1. Background 

A new version of OAIS with an ungraded version of 
software and an enhanced orderwriting module was implemented 
two days ago. These changes were the first major changes 
made to OAIS. A combination of Data Processing Technicians 
and contractor personnel worked on the programming portion 
of development. There had been little liaison between OAIS 
project team members and no separate test vehicle to support 
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on-line testing of OAIS changes. Up until this point, OAIS 
had been the darling of Naval Military Personnel Command 
both for the enhancements it had made to the officer 
distribution process and its ability to provide up-to-date 
information. 

2. Command Decision 

CAPT Williams, NMPC-47 Department Head, slowly 
walked back from conferring with his boss. Admiral Duke. 
Admiral Duke was the head of the Distribution Division. The 
hastily-called meeting concerned the poor performance of the 
new version of OAIS that had just been implemented two days 
previously. Admiral Duke had received numerous complaints 
about OAIS' slow response time and downtime (unavailability) 
from the department heads responsible for Surface, Aviation 
and Submarine officer distribution. As usual. Admiral Duke 
wanted to know why. He did not understand computer 
terminology and thus it was even harder for CAPT Williams to 
explain the complications. All the Admiral understood was 
that orders were not being processed and sent out. 

Several options had been discussed at an earlier 
meeting with NMPC-47 branch heads. One option was to keep 
OAIS up so that the problems and causes of the slow response 
time could be determined. The contractors favored this 
approach since the majority of the change was the newly 
converted software code. The disadvantage of this option 
would be a continued lack of orders and with the slow 
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response time, many users would not use OAIS. The users 
wanted the old version of OAIS back so that they could get 
orders out. By going back to the old version, several 
enhancements lobbied for by the users and an enhanced 
orderwriting module would be lost. These users were still 
the first generation of users and remembered life without 
OAIS. They had no experience with making the best even 
better. NMPC-47 realized that going back to the old version 
of OAIS would mean a loss of credibility with users and 
other organizations and an increase in resources necessary 
to solve the problem off-line, including manpower, dollars 
and time. Production issues involved getting OAIS JK back 
on-line, running all the updates from external interfaces 
and cancelling the updates generated by the new version of 
OAIS to external interfaces. The users would lose all the 
work that they had been able to get done on OAIS 1.7 and the 
time needed to get OAIS JK running again would cause OAIS to 
be unavailable to the users. 

CAPT Williams told YN3 Smith to contact the branch 
heads, CDR Rice in charge of N470, Information Systems 
Development branch; CDR Griffin in charge of N471, 
Information Systems Support branch; CDR Hazel in charge of 
N472, Order Support branch; and LT Hopkins who was the OAIS 
Project Officer. All players had met on numerous occasions 
over the past two days trying to determine just what the 
cause of the OAIS problems was. Once everyone was assembled 
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in his office, CAPT Williams announced his course of action. 
"Take OAIS 1.7 down immediately and restore OAIS JK (old 
version) as soon as possible. At yesterday's status meeting 
I was told it would take 14 hours of contractor time to 
restore the old version. I want an estimate of when the old 
version of OAIS will be available for detailer use. Jeff 
(CDR Hazel), I want your staff to work overtime if necessary 
to get any priority orders out manually. That's all." 

It was a silent group that walked out of the CAPT's 
office. Very rarely had they seen the CAPT this angry. CDR 
Rice was fuming. OAIS was his pet project and had been the 
darling of NMPC until the past few days. LT Hopkins, a 
recent graduate of the Naval Postgraduate School, could not 
believe how wrong things had gone. CDR Hazel thought to 
himself, I tried to tell them it wasn't ready and shouldn't 
be implemented. Now we'll all have to live with the 
consequences. 

3. Responses 

CDR Griffin was the most recent addition to NMPC-47, 
having been on-board only four weeks. CDR Griffin was also 
a recent graduate of the Naval Postgraduate School. He did 
not want to have to tell CAPT Williams that it would take 
more than 14 hours of downtime to restore the OAIS JK 
version. CDR Griffin thought the project office people 
always conveniently seemed to forget the production portion 
of the business. 
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User confidence in OAIS was shaken. There were some 
dissatisfied users due to promises of enhancements to be 
contained within OAIS 1.7, which were now delayed for an 
indefinite period of time. 

Tempers were high and finger-pointing was rife 
within NMPC-47 and SAGE. DPI Brown, who was in charge of 
the Navy's portion of the joint effort between the 
contractor and the Navy, bore the brunt of the blame. The 
attitude and arrogance on the part of the DP's was 
criticized. 

The main problem identified with OAIS 1.7 was 
degraded system performance due to the enormous demands made 
on the system from the converted code. This slowed response 
time to users and overtaxed the Central Processing Unit 
(CPU). When CAPT Williams had the new version of OAIS 
brought down, SAGE, the contractors, were all for keeping 
the new version up so that they could understand and work 
with the problem. 

LT Hopkins adopted two changes to her management 
techniques of OAIS. She decided to modularize OAIS into 
smaller portions and have test plans drawn up for each 
screen, module, program and interface of OAIS. 

4. Contract Change 

About this time, OP-01, the department in charge of 
manning plans for the Navy, slashed the DP manning 
requirements for NMPC-47. NMPC-47 knew that they did not 
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have the personnel nor the expertise to maintain OAIS. This 
big change to the game plan required internal and external 
changes. 

In June 1986, SAGE was approached by NMPC-47 top 
management personnel, CAPT Williams and Mr Smith, concerning 
taking over the maintenance of OAIS in addition to their 
current responsibility for development. This change in 
tasking required changes to the contract. 

During this renegotiation, SAGE demanded that they 
be given full control over DAIS programming. A prime 
complaint of SAGE's was a lack of control for the full 
system when part of the j. jgramming was being done by Navy 
DP's. SAGE attributed this lack of control to being a major 
cause of the recent failure. Having complete control would 
enable the contractor to have complete confidence in and 
responsibility for the results when it came time for 
implementation again. 

E. CASE STUDY FOUR 
1. Background 

NMPC-47 had just put the old version of OAIS back 
into production after two days of user complaints concerning 
slow response time. It was the first time a major problem 
had developed with OAIS. LT Hopkins made two changes to her 
management techniques. She wanted OAIS broken into modules 
and test plans developed for each screen, menu and program. 
The contractors took on the responsibility for both OAIS 
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development and maintenance. It was a time for coming up 
'ith solutions to the OAIS problems and organizational 
change. 

2. Transition of N471 to a Full Production Division 

Throughout the fall of 1986, NMPC-47 experienced the 
growing pains of transition from a development-oriented 
division to one where production was of growing importance. 
Up to and including the present time, the day-to-day running 
of the department was driven by CDR Rice's priorities and 
those of his project officers. Even though OAIS was a 
production application with all intended users on-line, OAIS 
was handled as an application still under development. 

The day-to-day decisions concerning OAIS production 
issues were handled by LT Hopkins. These included 
production-oriented decisions such as scheduling of batch 
jobs, updates, downtime, user impact, running of OAIS user 
meetings, production of OAIS User Bulletins and 
responsibility for daily messages on the OAIS sign-on 
screen. 

The failure of OAIS 1.7 seemed to highlight these 
growing pains and brought into focus such issues as matrix 
management, customer support and training. The bottom line 
was that users had become highly dependent on OAIS for 
accomplishment of their daily work. 
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3. CDR Griffin Changes to N471 

CDR Griffin was the primary force behind the 
transition of the Information Systems Support branch, N471, 
into the branch responsible for production decisions. In 
addition to the issues of customer support and training, 
systems maintenance and production scheduling were becoming 
more and more important. The informal matrix management 
established between CDR Rice and CDR Griffin's predecessor 
was done away with. Training was moved from N470 to N471. 
See Figure 4. 

CDR Griffin changed the mission of the error 
research personnel from being responsible for a portion of 
the OAIS user interface to being responsible for all 
customer liaison with OAIS users. The name of this newly 
tasked division was the OAIS Help Desk. LT Perkins, the 
current Training Officer, was identified as the logical 
person to heal up the OAIS Help Desk because of her current 
involvement with the assignment and placement officers and 
her functional knowledge of OAIS. 

A training room was set up in an unused conference 
room. Approximately eight extra terminals were set up for 
training of either individuals or groups of users. 
Scheduling of the conference room was the responsibility of 
the training officer. Training evolutions had first 
priority for usage of the room. The room was windowless 
with no air circulation or ventilation. 
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Figure 4. NMPC-47 Organization, May 1987 


CDR Griffin developed an NMPDS Crisis Management 
Team. This team was composed of an expert from each area of 
N471. These areas included Configuration Management, OAIS 
Help Desk, Systems Administration and a variety of other 
people depending on the problem. This group was headed by 
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CDR Griffin and manned by technical personnel, not managers. 
Problems were explained, solutions discussed and a decision 
to remedy the situation was made immediately. See Figure 4. 

4. Conflict Between N470 and N471 

There was conflict between N470 and N471 primarily 
due to allocation of resources between application develop¬ 
ment and application production. Up until this point in 
time, the emphasis in NMPC-47 had been on development 
issues. OAIS expertise had existed only in N470, the 
Information Systems Development branch. With OAIS usage 
growing and subsequently dependence on the application, 
other considerations were necessary. Maintenance of systems 
software and hardware were a necessity. Additionally, 
confusion on reporting responsibilities that a matrix 
management system wrought on functional management was 
exhibited. 

LT Perkins and LT Hopkins were constantly at logger- 
heads over responsibility of the day-to-day activities of 
OAIS. Both CDR Hazel and CDR Griffin agreed with LT Perkins 
that operational control of OAIS belonged in Information 
Systems Support branch, N471, vice the Information Systems 
Development branch, N470. 

The offices of LT Hopkins and LT Perkins were 
separated by two long hallways. LT Perkins’ office was 
located next to the OAIS Help Desk and Systems 
Administration where OAIS operations were monitored. When a 
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glitch developed during the course of a work day or a crisis 
was identified, LT Perkins had to consult with LT Hopkins. 
This wasted valuable time concerning both a fix and 
notification to the users as to OAIS status. This wasted 
time during a crisis added to the adversity between LT 
Hopkins and LT Perkins. 

Not only was there a struggle between LT Perkins and 
LT Hopkins, but there was one between the branch heads, CDR 
Griffin and CDR Rice. There was disagreement when it came 
to allocation of resources, both personnel and money, as 
well as the priorities of systems maintenance and 
enhancement versus software development. Systems 
maintenance was continually put off until there was time for 
it. Time seemed to be found on Saturday and Sunday 
mornings. 

By the spring of 1987, full control of day-to-day 
operations of OAIS were within N471, the Information Systems 
Support branch. The upcoming retirement of CDR Rice 
hastened the process. CDR Rice's replacement was LCDR Wall. 
LCDR Wall was more receptive to new ideas, more politically 
oriented, as well as being junior to CDR Griffin. 

LT Perkins took over full responsibility for 
production decisions and scheduling of batch jobs. She also 
took over responsibility for OAIS User Bulletin publishing 
and distribution. 
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5. OATS Help Desk 


The mission of the OAIS Help Desk was to improve the 
current level of user assistance. Instead of OAIS users 
having to contact various representatives within NMPC-47 for 
assistance with different problems, the OAIS Help Desk would 
be the single point of contact. This included questions on 
OAIS usage, orderwriting, hardware problems, updates of 
information and the status of OAIS. 

Naturally there v. ire growing pains. NMPC-47 workers 
had to learn to say, "Havt you contacted the Help Desk?" 
instead of running out to j.ix a problem. There was extreme 
difficulty in areas wherr ego was associated with power. 

One of these areas was hardware maintenance. It was very 
hard for the hardware maintenance personnel, who up to this 
time had been worshipped as heros due to their knowledge of 
computer hardware, to become part of a total customer 
service concept. Also users had found shortcuts or their 
favorite helpers and constantly called them. 

The enlisted personnel manning the help desk phones 
had to increase their knowledge of OAIS as well as learn 
patience for frustrated users. When OAIS did not work 
correctly, was down or contained bad information, the people 
that bore the brunt of user frustration were the OAIS Help 
Desk personnel and LT Perkins. If an officer was not 
satisfied with the answers provided by the OAIS Help Desk, 
they would call CDR Griffin, CDR Rice or even CAPT Williams. 
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Users had to learn that the OAIS Help Desk would get the job 
done. 

The phone calls to LT Hopkins concerning OAIS Help 
Desk issues were of particular note. LT Hopkins would 
usually proceed to investigate the problem on her own 
without infonning LT Perkins until later. 

LT Perkins spent a lot of her time educating users 
with reminders of, "Next time please call the Help Desk" and 
building customer trust in herself and her personnel's 
performance. 

6. OAIS Help Desk Phone Log 

A phone log procedure was implemented in order to be 
able to track incoming requests and to conduct a follow-up 
when users called again. Several cases of help requests not 
being fulfilled, with users complaining to CDR Griffin, 
fueled this change. 

User name, time, date of call and complaint were 
logged. Calls pertaining to hardware problems or User Id's 
needing reset were given a control number and sent to the 
appropriate section of N471, the Information Systems Support 
branch for correction. This process established an auditing 
activity of the log book by LT Perkins from which she could 
detect the flavor of calls and identify any particular 
trends or problems pertaining to training. 
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7. Growth of User Base 


As each day went by, the number of users on OAIS and 
GDIS continued to rise steadily. Requests were received 
from outside of NMPC for access to the application. A major 
policy decision was made that NMPDS information was just for 
Distribution Department purposes. Problems were encountered 
as the number of users increased. 

8. Port Pirates 

There were more terminals than there were ports on 
the bus interface units of the local area network. Primary 
users of NMPDS were designated as NMPC-4 and NMPC-2 
personnel. Other users were secondary. Primary users were 
assigned by division, a range of port numbers (one for every 
user) which were theirs to use. Specific port assignment 
was left up to a division. Secondary users were assigned a 
few port numbers. The policy for secondary users was use 
OAIS and then sign off the port so that other personnel 
could have access. If more personne] than there were ports 
available wanted to get on OAIS, they had to port pirate. 

Port pirating involves trying various port numbers 
to see if they were vacant to get on OAIS. If a primary 
user's port was pirated he would call the help desk for 
resolution. The port pirate was bumped off the pirated port 
and the primary user was able to sign on. Particularly on a 
Monday morning, a large amount of the calls to the help desk 
were those complaining of port pirates. 
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9. OAIS Dependence 


A crisis seemed to develop quickly whenever a 
problem with OAIS occurred, whether it be a bad back-up tape 
from the Officer Master File (OMF) or a hardware failure. 
This crisis environment was due to the heavy dependence of 
assignment and placement officers on OAIS. Also, senior 
personnel within NMPC had come to rely on OAIS to supply 
them with information on personnel, tracking of orders and 
for answering questions from Admirals and the Fleet. Due to 
this dependence on OAIS, CDR Griffin required LT Perkins or 
one of her personnel to personally deliver an OAIS User 
Bulletin or message concerning OAIS downtime to NMPC-47's 
Captain and the Admiral (NMPC-4). 

10. Experienced Users 

The users were becoming comfortable with computer 
usage and OAIS. With this comfortableness the users started 
coming up with better ways of doing things and ideas on 
automating other parts of their workload. Their ideas were 
turned into LT Hopkins in the form of a Software Change 
Proposal (SCP). LT Hopkins' response was that NMPC-47 would 
consider the changes after the new version of OAIS came up. 

It was during this timeframe that shortcuts to 
circumvent the chop chain and unprotected data fields within 
OAIS were discovered by the OAIS hackers (expert users). 

When these were discovered by NMPC-47, fixes were quickly 
implemented. One of the hacker changes included using one 
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of the orderwriting screens for sending messages to other 
personnel in the chop chain. This discovery prompted an 
addition of a message screen for such a purpose in the new 
orderwriting menu to be implemented with the 1.7 conversion 

The Aviation Department was using a screen designed 
for the Submarine Department. The screen was designed to 
keep track of hulls and Unit Identification Codes (UIC) 
assignments for new submarines, but the Aviators were using 
it for their in-house telephone directory. 

Other abuses of OAIS included personal utilization 
of information covered by the Privacy Act. Such abuses 
included checking out a medical doctor or lawyer's history 
and fitness reports prior to using their services. 

Screen by screen access was monitored by 
Configuration Management. Decisions concerning access or 
denial of access came through the chain of command of a new 
user, to their user representative and lastly to LT Perkins 
for final approval. One security precaution had been 
specifying the rank level for fitness report review. For 
example, an Ensign was typically granted access to only 
Ensign or Lieutenant Junior Grade fitness reports unless 
their job required other access. 

11. OAIS user meetings 

OAIS user meetings were held on an as-needed basis. 
They were called for and run by LT Hopkins. User 
representatives from each division attended on a sporadic 








basis. The focus of each meeting was usually development- 
oriented. Users continuously turned in additional 
requirements and enhancements for OAIS to LT Hopkins. All 
change requests were put on hold until OAIS 1.7 was 
implemented. LT Perkins attended these meetings, but rarely 
had anything to discuss save trouble reports called in to 
the OAIS Help Desk. 

12. OAIS User Bulletins 

Information concerning OAIS was also promulgated by 
use of OAIS User Bulletins These OAIS User Bulletins were 
sent to every OAIS user on an as-needed basis. Green paper 
was used so that they wo- i be easily distinguishable in a 
basket full of papers. Information such as scheduled 
downtime on a weekend or a trend of problems noticed by the 
help desk were contained on a User Bulletin. 

13. Training 

LT Perkins was still the Tr.. ling Officer. Training 
continued as before. Some departing OAIS users scheduled 
training for their reliefs as they new the full value of 
training by LT Perkins. In other divisions new personnel 
decided they did not have time for training in the short 
turnover period. New users got some on-the-job training 
from their predecessor and any problems they encountered 
they called the OAIS Help Desk. 

These calls required OAIS Help Desk personnel to 
become quite familiar with all aspects of OAIS and brought a 
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slight change in their mission. Instead of just correcting 
errors in the final product, orders, or notifying the 
correct department for a hardware problem, OAIS Help Desk 
personnel learned to operate screens and understand the 
various portions of the officer assignment process. The 
acquisition of the whole picture at the help desk increased 
the number of "experts” on OAIS, who could be turned to in 
times of crisis. 

14. Morale of N47's Data Processing Technici?^ns 

Morale of NMPC-47 DP's v;as a constant concern. Many 
of the positions were filled by first class or personnel on 
their first tour with the Navy. First class tours were six 
years. Unless they were able to get into the elite groups 
of the Information Center or Systems Administration, many 
got out. Personnel new to NM?C“4'7 were started out either 
at a help desk or in Scheduling. The Data Processing 
Technicians viewed the help desk job as that of secretary, 
which in their minds was a far cry from being a computer 
programmer. After some time they could be moved to other 
parts of the branch, in which their training would be of 
use, but there was no designated path of career progression. 
Changes in job description and division were determined by 
performance and vacancies. The expert status conveyed upon 
the members of the OAIS Help Desk significantly increased 
their morale. 
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The majority of DP's want to program. There was 
little programming to be done due to the integration and 
sharing of resources called for in the NMPDS plan. It was 
an accountability matter for the contractors that if they 
are held responsible for the program, they did not want, 
anyone else to be allowed to make changes to it. The DP's 
responded to added pressures and high cost of living, which 
is synonymous with working in Washington D.C. at a 
headquarters command, by getting out of the service. Many 
were able to find lucrative jobs with computer companies and 
make more money. 

15. System Administration Improvements 

A test environment for OAIS, called TOAIS, was 
developed by the Systems Administration division. With CDR 
Griffin giving Systems Administration the emphasis it 
needed, future plans for hardware and software were 
expanded. 

a. Security 

A major issue in October 1986 was the 
introduction of a security system for signing into NMPDS. 
This security system would increase overall security and 
data integrity. The current procedures required specific 
signon procedures for each of the applications under NMPDS. 
The goal was a standard sign-on procedure. The first -ep 
was incorporation of an overall shell security system, 
called RACF, which when successfully accessed would allow 
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access to the other applications within NMPDS with their 
individual passwords. With RACF in place, users were 
required to remember their RACF password and their password 
for each application. 

When RACF was implemented it was discovered that 
many users did not have their own User Id's, but used those 
of other personnel. This was z security violation. Each 
user is given capabilities and access to certain screens 
within DAIS based upon the job they are to fill in the 
assignment process. It was also discovered at this time 
that some assignment and placement officers had given their 
User Id's to their secretaries to do their work. In essence 
this was also a security violation as well as an avoidance 
of using OAIS. 

It took a lot of work to get the RACF system 
working properly. Users had to acquire User Id's and they 
frequently forgot their password and had to call the help 
desk to have it reset. The help desk personnel had to 
ensure that the person who was calling for a User Id reset 
was actually the user. 

b. NMPDS Dial-Up Capability 

Users had become more and more dependent on OAIS 
and ODIS. To facilitate detailer trips to the field, a 
dial-up capability for OAIS and ODIS was implemented. 

Through the establishment of an 800 number, procurement of 
lap-top microcomputers and modems with secure calculator 
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generated passwords, detailers were able to access OAIS and 
GDIS from the field. This greatly decreased their manual 
paperwork, impressed constituents in the field and increased 
constituent confidence in the detailing system. 

If a detailer trip was going to the west coast, 
special arrangements were made through the help desk to have 
OAIS stay operational longer than the usual downtime of 
1800. This delayed backups '.id batch jobs in the evening, 
put if planned far enough in advance, could be handled 
without difficulty or delay in workload. 

16. Software Maintenance for OAIS 

Maintenance to the older version of OAIS was being 
done by the DP's in the Application Programming Shop within 
N470, the InfoiTtiation Systems Development branch, on an as- 
available basis. This maintenance tasking was to be just 
until OAIS 1.7 came up. The contractors did not have enough 
personnel to handle development and maintenance due to the 
recent contract change. 

Most of the changes were maintenance-oriented, with 
only a few high priority development changes. The change 
process involved changes to the program but no changes to 
documentation. The development-oriented changes included 
giving OAIS the ability to handle the processing of Release 
from Active Duty (RAD) orders. Resignation orders and 
Retirement orders. The change for RAD and Resignation 
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orders occurred in December 1986 and the change for 
Retirement Orders occurred in March 1987. 

These changes increased OAIS's usage. Previous to 
this, Resignation and Retirement (RAD) orders had to be 
./ritten manually. The manual process took far too long and 
chops on the orders were needed from a variety of personnel 
serving in several different divisions. Personnel in CDR 
Hazel's division had to type these manual orders. CDR Hazel 
was always looking for ways to improve OAIS and reduce 
manual work. He worked closely with the N470 programmers to 
have OAIS changed to accommodate these two order formats. 

With a few small exceptions, all types of orders 
could now be written on OAIS. Due to the changes made by 
CDR Hazel, the orders which still had to be typed manually, 
due to OAIS's inability to handle them, were down to 
approximately five a day. This is a significant amount when 
approximately 30,000 sets of orders (basic orders and 
modifications) were sent out annually. NMPC-2, who is 
responsible for RAD, Resignation and Retirement orders, was 
now a full-fledged user of OAIS. 

17. ODIS Improvements 

During this time, rapid advances and changes were 
being implemented in ODIS. These changes made the life of 
assignment and placement officers easier. The ability to 
get Officer Data Cards (ODC) by social security number from 
ODIS was implemented in December 1986. Officer Data Cards 
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carry a condensed version of an officer's personnel history 
on a single sheet of paper. These ODC's were handy for 
quick reference and detailing trips. GDIS was able to 
provide a one to two day turnaround as opposed to requesting 
the service from NMPC-16 and waiting a week to ten days. 

GDIS training and abilities were advertised heavily 
during this time. Many of the reports and information 
changes that assignment and placement officers desired and 
had submitted in the form of Software Change Proposals 
(which were on hold until ■<mplementation of the new version) 
were available through the iatabase of GDIS. GDIS was not 
quite as "user friendly" as GAIS. Commands were in an 
English-like language and knowledge of some boolean algebra 
was required to operate the database. The Information 
Center was available for assisting users with GDIS. 

Additionally, through GDIS, an electronic mail 
system was available to all users. The electronic mail 
system required a separate password, as did GDIS usage. 
Electronic mail was utilized on a s oradic basis throughout 
NMPC-4 with some departments taking i.ull advantage of the 
system and others ignoring it. 

18. Contractor Project Management 

Throughout July and August of 1986, the contractors 
tore DAIS apart, broke it down into workable size modules as 
per LT Hopkins' direction and identified areas requiring 
work. LT Hopkins allowed the contractor to start from 
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scratch in fixing bugs and prograiruning/redesigning Navy 
code. 

In September, the contractors requested an OAIS 
functional expert from the Navy to assist on a daily basis, 
to make decisions and guide fixes on the reprogrammed 
version of OAIS. LT Hopkins knew she did not have the 
expertise to assist the contractors, but at the same time 
she felt the need to be continually looking over their 
shoulders. 

CDR Griffin wanted CDR Hazel to be this functional 
expert. CDR Griffin was determined to have OAIS 1.7 work 
the next time it came up, as his division bore the brunt of 
user dissatisfaction. 

CDR Hazel wanted to be the functional expert 
assisting the contractors. He had also borne some abuse 
from the assignment and placement officers for the failure 
of OAIS in May 1986, being the closest to them due to his 
previous job as Training Officer. CDR Hazel felt like one 
of the plank owners of OAIS. He felt he owed it to himself, 
the department and the users to make it work. CDR Hazel 
felt he finally had someone on his side in the form of CDR 
Griffin. Both knew user issues came first and worked 
towards this end. 

CDR Griffin had to take the decision concerning 
designation of the functional expert to CAPT Williams as CDR 
Rice did not want CDR Hazel involved. CDR Rice and his 
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project officers were responsible for liaison with the 
contractor and wanted to keep it that way. LT Hopkins did 
not have any objections to CDR Hazel's involvement, she 
wanted to get back out there with a quality product. 

CDR Hazel was designated as the functional expert to 
assist SAGE. He spent every day of September and October 
with the contractors. He assisted in the identification of 
bugs, instructed on fixes and made decisions on functional 
issues. He was also able to correct minor things which, 
though of a low-level priority, still bothered him. These 
included standardizing messages and making error messages 
understandable to the users instead of being in programmer 
code. CDR Hazel was on his own. CDR Griffin and LT Perkins 
occasionally asked him how things were going. 

In November 1986, it was announced that OAIS 1.7 
would be implemented in March 1987. 

The contractors spent most of the fall and winter of 
1986 converting OAIS code from JK to 1.7. The code 
conversion had originally been planned to be a straight 
1ine-for-line conversion in view of the design standard of 
upward compatibility between different versions of APSCOBOL. 
It was discovered during the preliminary testing of module 
integration that more than straight line conversion was 
necessary. Modules had to be completely reworked to conform 
to the new methods of how the programs were called and how 
transportation from screen to screen was handled. The new 
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version of APSCOBOL required more overhead due to the logic 
changes in the software. Rewriting the logic behind the 
OAIS screens and programs was time-consuming, but the 
advantages of more efficient code outweighed the costs 
involved. 

Another major effort was the development of test 
plans. One of LT Hopkins* directives after the May 1986 
failure was the development of test plans. Test plans were 
written by SAGE personnel and reviewed by Navy personnel. 

LT Hopkins, CDR Hazel and LT Perkins reviewed the plans for 
the Navy. 

In February 1987, SAGE designated V. Hammer as the 
new project manager for OAIS. She had previously worked on 
a contract dealing with the Officer Master File (OMF), so 
she had some experience with officer systems. 

V. Hammer found three major areas needing work when 
she took over the project. Two of these areas were within 
OAIS. One was converting the code for all the batch jobs 
and reports and verifying the Job Control Language (JCL) fer 
each. The second area concerned interface testing with the 
applications that OAIS provided information to. Of 
particular concern were the interfaces of the OMF, MFS and 
0PM. 

The 0PM was under a different project at SAGE as 
well as being managed by a separate project officer for the 
Navy in the Information Systems Development branch, N470. 
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One person, Mr. Donaldson, was working on the 0PM when V. 
Haimer took over the OAIS project. The majority of work 
being performed by Mr. Donaldson concerned getting the 
orders through the Communication Center edits. V. Hammer 
immediately went to her boss to express her concern over the 
status of the 0PM and its importance to the OAIS project, 
but to no avail. 

V. Hammer set her personnel to working on the 
changes needed in OAIS reports. She worked on the OMF 
interface, having knowledge of its workings from her 
previous project. She got the OMF interface error rate down 
to about five percent, a much lower figure than the current 
interface between OAIS and OMF. 

19. Conversion Plans 

In February, the Navy decided that due to a large 
amount of user work in OAIS JK, they could not just take 
OAIS down and replace it with another version without 
causing undue hardship to the users. A parallel conversion 
was decided upon and SAGE drew up conversion plans. V. 
Hammer added some slack time to the estimation of effort it 
would take to do the conversion in order to give 0PM testing 
more time. Up to this point the 0PM had failed every part 
of the test plan devised for it. 

The implementation date for OAIS was moved from 
March to May 1987. 
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The reasons behind the push for production of 0PM 
included in-house responsibility for order generation 
instead of having to rely on NMPC-16, and having officer and 
enlisted orders in the same format. This would facilitate 
processing at the Personnel Support Detachments as well as 
providing orders to military personnel that they could 
understand. 

2 0. Systems Stress Test 

In late February 1987, a systems stress test was 
planned to test how the newly converted software code worked 
with the hardware. It was necessary to have users on OAIS, 
both so the Central Processing Unit (CPU) could have a load 
and to test the interface between various parts of the new 
application, particularly those interfacing with the 
orderwriting module. The test was scheduled from 1500-1530 
on a Friday. 

Production OAIS was taken off-line during the test. 
Users were informed by OAIS User Bulletin and given specific 
instructions on what processes to carry out. User 
representatives also were informed at an OAIS user meeting. 
User representatives and OAIS Help Desk personnel were 
available in the user spaces for assistance and for 
identification of problems. Since it was a Friday, there 
was very little participation by the users. 

A second stress test was scheduled for a Thursday 
afternoon. CAPT Williams explicitly requested user 
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participation at the weekly department head meeting with the 
Admiral. Procedures were as before, users were notified by 
OAIS User Bulletin, and user representatives and OAIS Help 
Desk personnel were in user spaces for assistance. 
Participation was much better. 

21. Pre-implementation 

Testing was scheduled to last for six weeks starting 
in March. Testing was conducted using user representatives 
and experts on specific portions of OAIS. Testing took 
place in the training roon for several hours each afternoon 
during the month of April. Washington D.C. experienced a 
heat wave during this ti: ■ It was hot and stuffy within 
the unventilated training room. The test plans were used as 
a guide and user representatives verified that menus, 
screens and procedures worked correctly. Areas that worked 
correctly were signed off by the users. Test orders were 
generated and used to test the 0PM. CDR Hazel and LT 
Perkins facilitated the testing along with two of the 
contractors. LT Hopkins looked in occasion. TOAIS was 
of very small size, holding only 100 records, a small number 
in comparison to the normal 70,000 records of active duty 
officers. Systems personnel were assigned to monitor TOAIS 
and unlock problems before they brought the computer system 
to a standstill. At the end of each session, CDR Hazel 
prioritized problems identified with the concurrence of LT 
Perkins and the contractors. Priority categories were: fix 
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before implementation, fix within a few weeks of 
implementation and nice to have. OAIS seemed to work fine. 
The Order Production Module was not quite finished during 
the test period, but bastardized procedures were available. 
The only other system interface which was tested during this 
time with the OMF-OAIS interface. Preliminary tests showed 
no problems. 

During the testing phase, more personnel were 
assigned at SAGE to work on the 0PM. New tests still showed 
that the 0PM did not work. V. Hammer took the issue to her 
boss once again. She also talked to LT Hopkins and gave her 
the proof of failure with the completed and unsuccessful 
test plans. LT Hopkins took the issue to her boss, CDR 
Rice, who ignored the proof and said bring up OAIS anyway. 

22. Training 

Some training for user representatives was conducted 
during these testing sessions by LT Perkins, CDR Hazel and 
the contractors. Changes to the orderwriting module were 
promulgated through a new version of the OAIS User Manual. 
Training on a large scale basis for all users was not 
possible due to the nonavailability of TOAIS. When testing 
was not going on, the contractors required use of the TOAIS 
application to test and implement software fixes to problems 
identified in prior testing sessions. LT Perkins hoped that 
once the new version came up, that the individual user 
representatives would help train the personnel in their 
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departments if required. The idea of user representatives 
assisting personnel in their departments was presented 
during an OAIS user meeting. The personnel manning the OAIS 
Help Desk were trained through participation in the testing 
sessions and having some early morning access to TOAIS. 

Their expertise would be of assistance to users with who are 
unfamiliar with the new procedures. 

LT Hopkins coordinated with LT Perkins to put out a 
series of OAIS User Bulletins describing some of the new 
procedures. The plan was to initiate new orders and 
modifications to old orders on the new version and to use 
the cld version for orders still within the chop chain. To 
ensure proper usage of the new version, several screens in 
the old version were disabled. Arrangements were made with 
Scheduling to have contractor personnel on hand for at least 
the first week of producing orders to assist the scheduling 
personnel. 

LT Hopkins did not want to bring up OAIS 1.7. There 
were too many problems with the OAIS-Order Production Module 
interface. LT Perkins and CDR Hazel also felt that the new 
version was not ready. They were very familiar with the 
problems existing with OAIS through their participation in 
the testing. Even though contractor personnel were working 
overtime, many fixes to problems discovered during testing 
had not yet been implemented. CDR Hazel voiced his opinion 
at a branch head meeting run by CAPT Williams and attended 
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CDR Rice 


by the branch heads, CDR Rice, and CDR Griffin, 
said, "I want OAIS operational before I retire. We have 
been advertising that it would come up for six months." 

23. OAIS 1.7 Changes 

The majority of changes revolved around the new 
orderwriting process and utilization of the 0PM instead of 
AUTONOM. Some of the changes to the orderwriting process 
included: 

Default setting for mode of transmission changed from 
message to letter. Orders are designated as 
administrative message traffic and the decision was 
made by the Admiral that unless the orders were to be 
carried out in 30 days, letter was the designated mode 
of transmittal. 

On-line help with order format. If a user was unsure 
about what order format to use on a particular set of 
orders he could fill in just the first digit and get a 
list of all foirmats from which to pick. Also if a user 
was unsure about a particular text to put in a set of 
orders, he/she could call up all the text and read 
verbatim what would be printed on the orders. 

Change of text linkers to be more user friendly. Text 
linkers are used to designate which part of the orders 
a specific text applies to such as detaching, 
intermediate or ultimate. In OAIS JK, these linkers 
were letters with no significance to the user as they 
were an exact copy of the manual document, the Officer 
Assignment Document. New linkers possessed some 
natural linkage to the subject, D was for detaching, 
and U was for ultimate. 

Change of costing information. If a set of orders was 
to be modified in OAIS JK, a delta figure (plus or 
minus) was incorporated in the orders. For a 
modification in OAIS 1.7 the amount of money was 
entered without a delta. 

- A system was designed to notify a order writer when a 
UIC included in the orders being written was under 
minimize. If minimize was in effect, orders had to go 
by letter, as administrative message traffic was not 
allowed. 
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Incorporation of At or Near Location tables. OAIS 
automatically calculated if sites for training or the 
distance between two duty stations were close enough 
together to be costed as one location. Also the module 
automatically costed the per diem costs for training, 
alleviating detailers of this chore. 

Changes made to OAIS included the following, some of 

which had been user requested: 

Query by Name screen. To use OAIS, a person's social 
security number or Activity UIC was needed. The Query 
By Name screen allowed an OAIS user to enter the first 
seven letters of an officer's last name and OAIS would 
provide a list of matching personnel. The user could 
then select the one desired. 

Addition of a hold facility to the Action Queue. Quite 
often, a set of orders is ready to go but either there 
is no one identified to replace the officer, or there 
is not enough money to send the orders. Orders that 
were in a waiting status, caused individual assignment 
and placement officer's action queues within the chop 
chain to grow uncontrollable. With the hold facility, 
a set of orders could be designated a hold and moved 
off the action queue to a separate hold list. 

Upgrade of Security Access. Users could now have six 
desk codes identified in their security file, to which 
they could have access. This access was available 
without having to log off and log back on again with a 
different User Id. This upgrade was particularly 
useful for order verifiers who worked for several 
assignment officers. Also, when a user went on 
vacation, access would be available to his/her desk 
code. 


F. CASE STUDY FIVE 
1. Background 

NMPC-47 was again ready to implement the new version 
of OAIS with the converted code. The previous try, 
approximately a year ago, had ended in failure. The past 
year had been spent converting the code, correcting problems 
and recoding the orderwriting module. Within the 
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organization, a transition from a development to a 
production orientation had taken place. Responsibility for 
production OAIS had been passed to the Information Systems 
Support branch and resources were allocated to systems 
hardware and maintenance. 

2. Implementation 

The big day came on a Monday. The contractors, LT 
Hopkins, LT Perkins, and CDR Hazel made the OAIS Help Desk 
their headquarters as they waited for the calls to come in. 
a. Week 1 

The first type of problems uncovered had to do 
with the security access change. Each user was now capable 
of having access to six desk codes per User Id instead of 
one. Users had been told of this upcoming change by OAIS 
User Bulletin as well at OAIS User meetings, but there were 
people who had not gotten in their paperwork to 
Configuration Management to change their security profile. 

Most of the other problems the first day 
involved lack of training. Calls came in on how to use or 
update a screen. The first sets of orders under the new 
version of OAIS went out by message on Tuesday. There were 
13 of them. It was not discovered until after transmittal 
that instead of having a From of Chief of Naval Personnel, 
the From was PERSUPPDET Crystal City. The PERSUPPDET 
Crystal City address had been used in the test orders and 
had not been changed. 


72 





Orders under AUTONOM usually went out 
approximately 24 hours after costing had approved the 
orders. During the first weeks of 0PM processing, orders 
were held up for several days due to bad records being 
passed to the 0PM. The philosophy behind 0PM development 
was that the 0PM was never wrong. Procedures had to be 
devised to identify bad records on the first run of the 0PM, 
eliminate them and rerun the 0PM until there were no bad 
records. This took up an increasing amount of each night's 
processing time. Occasion -ly, work was not accomplished 
before it was time to bring OAIS up in the morning. 

The followin. 'roblems caused inconvenience to 

the users and needed a solution; 

A problem generated by the conversion process made 95 
sets of orders that had actually errored out of AUTONOM 
and that were AUTONOM rejects look like they had 
processed successfully. There was no way to correct 
these orders in either version for a few days. 

Several of the changes implemented in OAIS JK were not 
included in the new version. 

Automatic chop chain routing of orders to coordinator 
review and subspeciality when the orders did not 
require the edit. 

Every set of orders required transferring through the 
Minimize screen within the orde •writing menu, even when 
the UICs were not under minimize. 

Due to the orders going out with incorrect 
addressees, CDR Griffin required that each day's orders had 
to be reviewed prior to release. LT Perkins and CDR Hazel 
were designated as the reviewers. Through this review 
process, a major problem was discovered with aviation duty 
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wording. The aviation duty wording determines flying status 
and pay of aviation personnel. Orders were going out with 
incorrect flying status determination. Looking for a fix 
for this held orders up for three days. 

A Communication Center procedure that had to be 
kept in mind when holding up orders was that the Date-Time- 
Group (DTG) on the orders could not be more than seven days 
old. 

CDR Hazel and V. Hammer finally located the 
cause of the aviation duty wording error by going through 
the code line by line. CDR Hazel, being a functional expert 
on order specifics, was able to tell V. Hammer what was to 
print and V. Hammer was able to identify the errors in the 
code. 

The first week of 0AI3 1.7 ended. All 
personnel, contractors and Navy, had worked long hours and 
were exhausted, but the new version of OAIS had stayed up 
for a whole week, which was better than the last time. LT 
Hopkins went on leave for three weeks. Her boyfriend was 
coming back from a six month deployment on-board a ship, 
b. Week 2 

More problems developed with orders on the 

secoiid week. 

One hundred thirty sets of separation orders were sent 
out to personnel that were not due to separate from the 
Navy. 

Duplicate DTG's were discovered. This was in violation 
of Communication Center procedure. 
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Missing DTG's were discovered in the course of routing 
hard copy orders back to the originating assignment 
officer. OAIS showed that some orders went out on 
particular personnel with an assigned DTG, but no hard 
copy was ever found. Discovery of this problem changed 
the procedures involved in routing of hard copy orders. 

Previously, Order Support branch personnel had 
just sorted orders, keeping a copy for in-house records. 

Now they were required to verify against a DTG log actual 
receipt of hard copy orders. Missing orders were passed to 
LT Perkins who had been delegated liaison with the 
CoiTununication Center. 

Along with ownership of the 0PM came 
responsibility for bad magnetic tapes. Tapes that could not 
be read by the Communication Center were returned to 
Scheduling and the back-up tape submitted. Occasionally 
part of a tape was transmitted and in order not to 
retransmit messages, a violation of Communication Center 
policy, a copy of the partial tape had to be made by 
contractor personnel. 

The order verification process was made even 
more difficult by the poor quality of reports provided to 
the OAIS Help Desk. The report formats were just copies '^ 
the old reports from when AUTONOM and NMPC-16 were 
responsible for order tracking and verification. Now that 
NMPC-47 had full responsibility, more information was needed 
to fulfill this job. 

The change in the default value of the 
orderwriter to letter versus message caused a steep increase 
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in the number of orders that went out by letter. The 
sorting machine was quite old and acted up on occasion. 

With an increase in workload, the machine broke down at 
least once a day causing a letter backup. Letters had to be 
sorted manually on many a day by already-overworked 
personnel. 

From the first try at generating a MFS tape 
there were problems. It took about a week of working things 
out between NMPC 16 and Naval Finance Center in Cleveland. 

It wasn't until about two weeks into order production that 
the accounting problems with orders were discovered. These 
problems included: 

incorrect rank on the accounting line. 

missing accounting lines for training segments of 
orders. 

incorrect report not later than, report no earlier than 
dates. 

accounting data for training was printing on orders not 
requiring it. 

incorrect information in the at or near location 
tables. 

Messages and questions started coming in from 
the fleet concerning orders. There was missing activity 
text for certain Personnel Support Detachments, and 
misleading text for some orders The Communication Center 
also identified problems pertaining to the Standard Subject 
Identification Code (SSIC) used on orders messages and the 
use of asterisks to separate portions of the messages. 
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These discrepancies were pointed out by Communication 
Centers in the field. 

The Communication Center threatened to 
discontinue service to NMPC-47 on several occasions, but 
that threat became real when messages were transmitted 
starting with Date-Time-Groups having 26 as the time. The 
DTG goes on a 24 hour clock and there is no such thing as an 
hour 26. 

Minor inconveniences included several reports 
that were not printing and the Navy Times tape not being 
printed. The Navy Times tape became quite an issue as Navy 
Times said a lot of their readership was due to the orders 
published in Navy Times . Contractor time needed to correct 
order problems was diverted to the Navy Times issue. 

During the second week of crisis, CDR Hazel and 
LT Perkins were appointed project officers in LT Hopkins' 
absence. CDR Hazel dealt with 0PM fixes and telling the 
contractor what to do as they were of first priority. LT 
Perkins dealt with production issues such as liaison with 
Scheduling, Communication Center, order production, and 
fixing OAIS problems. Upper management instituted thrice 
weekly status meetings with SAGE, CDR Griffin, LCDR Wall, LT 
Perkins, CDR Hazel, and some of the technical personnel from 
both SAGE and NMPC-47. 
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G, CASE STUDY SIX 

1. Background 

NMPC-47 is still in a crisis mode due to the 
numerous problems with OAIS 1.7. DAIS has stayed 
operational, but at the expense of resources, primarily 
contractor overtime and NMPC-47 personnel. 

2. Aftermath of May Failure 

Day-to-day operations revolved around daily order 
production and retransmits! of orders if necessary. Once a 
day's order status (orders were or were not produced) was 
known, work could continue sn fixing trouble reports for 0PM 
and OAIS. The number of manual orders having to be typed by 
Order Support branch personnel increased from a daily- 
average of five to 75. There was a constant backlog. 

This crisis mode continued through the summer. LT 
Hopkins returned from leave and was told she was not to get 
involved with the production-oriented part of OAIS. In 
July, SAGE lost the OAIS contract to another contractor, 
SYSCCN. 

3. New Contractor 

SYSCON took over as contractor for OAIS in August. 
SYSCON was familiar with the workings of NMPC as they were 
the contractor for two other applications within NMPDS. 
Arrangements were made for the turnover of source libraries 
and system documentation to SYSCON. NMPC-47 acted as 
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intermediary, as there were hard feelings on the part of 
SAGE personnel. 

SAGE personnel involved .^ith the OAIS project felt 
quite bitter. They had worked overtime all summer without 
any breaks. Blame had been placed at their feet and 
everyone was calling OAIS a disaster when, in reality, OAIS 
was fine; it was the OPM-OAIS interface that did not work. 
Work on OAIS and 0PM trouble reports virtually came to a 
standstill during the months of July and August. 

LT Perkins trained the SYSCON personnel on the 
functional purposes of OAIS and exposed them to the language 
of the assignment and placement officers. 

SYSCON did an initial examination of the order 
generation problems. At the time they saw no way around the 
quick and dirty fixes implemented by SAGE, but planned for 
their demise in the near future. The thoughts of NMPC-47 
management were those of starting over with a fresh attitude 
and management style. CDR Griffin, CDR Hazel and LT Perkins 
were impressed with the experience that Ms. Green, the 
project manager at SYSCON, brought uo OAIS. Initial 
meetings with her consisted of honest, and in-depth 
explanations for OAIS problems. These things had not been 
forthcoming from SAGE personnel. Three SYSCON personnel 
were assigned to rotate staying with Scheduling to get 
orders out each night. 
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Personnel 


4 . 

LT Hopkins was moved to another project officer job. 
A junior LT, LT Sanders was promoted from within the Surface 
Department to become the OAIS Project Officer. LT Sanders 
had a user's knowledge of OAIS, but did not have a computer 
or software development background. 

LT Perkins and CDR Hazel were still in charge of 0PM 
and production OAIS issues, but LT Sanders was to get the 
development side of OAIS on the move again. 

CAPT Hampton relieved CAPT Williams in September 

1987. 

5. Organization Changes 

Several changes were made to the structure of the 
organization after CAPT Hampton arrived. Order Support was 
moved from the Order Support branch to the Information 
Systems Support branch. Scheduling was moved out of Systems 
Administration due to its increasingly important part of 
everyday happenings. The Information Systems Support 
branch, N471, was now completely customer service and 
production-oriented. A new division was created out of N472 
and was called Information Systems Policy and Procedures. 

It included Configuration Management which was moved out of 
N471 and Data Administration w.iicL was moved out of N470. 

See Figure 5. 

Another change implemented by CAPT Hampton was that 
training was mandatory for new assignment and placement 
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NMPC - 47 



Figure 5. NMPC-47 Organization, September 1987 


officers. By this time, there were two modules of OAIS and 
one for ODIS of computer-aided training developed by Oak 
Ridge Associated Universities. The computer-aided training 
utiliz-ed an IBM PC XT computer, a Pioneer Laser Disk and an 
ATI touch screen. Training was provided using voice 
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synthesis and touch screen technology that was interactive 
and user friendly. 

OAIS user meetings became mandatory under the 
direction of CAPT Hampton. Any user representative not in 
attendance was written down as absent in the weekly user 
representative meeting minutes. The minutes of each meeting 
were published as dictated by CAPT Hampton. 

6. Naval Audit 

NMPC-47 received notification of a pending Naval 
Audit concerning wasted paper due to unused and unwanted 
OAIS reports. 

7. OAIS Development versus OAIS Production 

The initial division of labor at SYSCON was three 
contractors working on production trouble reports with LT 
Perkins in charge and three contractors working on 
development and necessary changes with LT Sanders in charge. 

Two of these necessary changes were the addition of 
several data elements to the Activity File, one of the major 
applications OAIS interfaces with and implementation of the 
Joint Specialty Designation and its associated tracking/ 
chopping of orders which had been approved by Congress. 

These changes to the Activity File by EPMAC also 
involved moving the location of several data elements within 
the file. Plans were made for the change. SYSCON and LT 
Sanders spent an entire weekend of computer and contractor 
time trying to implement the change without success. LT 
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Perkins was not included in their plans even though she was 
an expert on OAIS. After the unsuccessful weekend, CDR 
Griffin and LCDR Wall decided to put off any development 
changes for several months. They decided that LT Sanders 
needed to learn more about OAIS and NMPC-47 operations. 

A problem uncovered during the implementation of 
this change was the inadequate and old OAIS documentation. 
One of the reasons there were problems with the 
implementation was because the documentation was incorrect. 

LT Perkins was in charge of all OAIS production- 
oriented work and had all six programmers working on 
production changes. CDR Griffin and LCDR Wall hoped that 
with all the time spent on production problems that some 
progress on long standing OAIS problems could be made. Of 
particular importance was the problem with the PRD data 
element. Assignment officers would update an officer's PRD 
and due to problems with the Officer Master File interface, 
the change would not reflect in the Officer Master File and 
the PRD would change back to its previous value in OAIS. 

8. Production Changes 

Plans were made and progress continued toward having 
the Navy personnel in Scheduling be the ones running the 
batch updates and order generation at night. 

A policy was implemented by CDR Griffin that 
whenever a fix was put into 0PM or OAIS, a SYSCON person 
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would be in Scheduling that evening to ensure that no 
problems were encountered. 

Another change was that all trouble reports were 
prioritized by LT Perkins. LT Perkins maintained a daily 
status of the progress made on individual trouble reports. 
User representatives were kept informed by weekly, mandatory 
OAIS meetings. 

LT Perkins instigated a policy of having the Navy 
test all software fixes generated by SYSCON. LT Perkins 
delegated most of the tesi -ng to her personnel at the OAIS 
Help Desk. Involving the x^slp desk personnel in the testing 
and scheduling of softwa^"? changes increased their morale. 

If it was a top priority trouble report she would also test 
the fix herself. 

LT Perkins preferred to implement the OAIS changes 
in the afternoon, preferably on a Wednesday or Thursday, so 
that the change would be available first thing in the 
morning. User representatives were informed of the 
implementation schedule at the weekly meetings. If a 
problem was discovered with the fix, it could be pulled out 
with only an hour of downtime. Thursdays and Fridays were 
usually slow for the users as the majority of their workload 
was accomplished in the early part of the week. These days 
also were slow days for Scheduling. They were usually 
caught up on batch jobs and had some spare time, which was 
needed in case a problem arose. 
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with Scheduling of more importance, several problems 
came to the forefront. Actually they had been problems for 
a long time, but never made it to the limelight. These 
included problems with non-standard run books and program 
naming conventions. The solutions were worked out with the 
Configuration Control Board (CCB), Configuration Management 
and SYSCON. These standards wouxd be incorporated in any 
new development or software fix. The CCB also decided that 
a period of review prior to implementation of a fix to 
ensure compliance with run book and adherence to standards 
would be implemented. 

Report distribution problems were also noticed. 

With the OAIS 1.7 implementation, several reports were not 
printing, some reports were printing incorrect information 
and there were now unwanted reports requested by personnel 
who had left NMPC. Report trouble reports had been given 
low priority during the summer, but with a Naval Audit being 
conducted, one of the junior programiiiers at SYSCON was 
assigned to fix all the report trouble reports. 

CDR Hazel instituted a new policy with respect to 
trouble reports for the 0PM. He regdred a requirements 
analysis be completed prior to submission of a trouble 
report to the contractors. This analysis would assist in 
establishing 0PM documentation. 


85 






9, OAIS User Participation 

For those trouble reports not identified as top 
priority, user representative input was taken on where they 
should fall in the priority scheme. LT Sanders was getting 
the paperwork side of the OAIS development in order. She 
collected approximately 200 SCP's that had been submitted 
over the past three years. Records had not been maintained 
very well and she was not sure if some of the changes had 
already been implemented. User representatives were asked 
to vote on the priority of SCP's for development. When a 
software fix to OAIS involved a specific procedure for a 
group of users, the applicable users would be asked to test 
the fix before it went into production. 

10. NMPDS Planning/Intearation 

A Configuration Control Board (CCB) was established 
in NMPC-47. Members included branch heads. Data 
Administration, Configuration Management, Systems 
Administration, Scheduling, project officers and help desk 
personnel. The purpose of the CCB was to review plans and 
changes to all four applications under the NMPDS umbrella. 
The plan was to ensure compatibility of all the applications 
under NMPDS for future integration and resource sharing. 

All software fixes and a plan fur implementing the fix were 
routed around to various members of the CCB for signoff 
before the weekly scheduled meeting. 
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At the weekly scheduled meeting, the initiator of 
the trouble report, usually LT Perkins, briefed the board 
members as necessary and advised them on the schedule for 
implementation. SYSCON was also invited to CCB's on an as- 
raquired basis. Their role was usually to e>:plain a lon^j 
range plan for correction of a problem. 

11. Electronic Mail Usage 

CAPT Hampton believed in the electronic mail system. 
He ensured command usage of electronic mail within NMPC-47 
by sending out all his messages to the branch heads on it. 
With top-down support, the branch heads implemented 
electronic mail into their routines. Usage traveled further 
down the chain of command until every manager made sure they 
read their mail everyday. 

By late November, the major problems with the 0PM 
were solved. The quick and dirty programs were still in 
place because replacements for them were quite involved. 

Some development efforts were started. OAIS users had 
settled down having seen affirmative action and improvements 
with new procedures. 
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IV. ANALYSIS 


A. INTRODUCTION 

This chapter analyzes each of the six case studies. 
Section One contains questions which can be used for two 
purposes: to help a student prepare the case or to lead off 
questions for a class discussion. Section Two is a suimnary 
of the case study. Section Three lists the major issues or 
problems that the case study deals with. Identification of 
these issues links potential lecture material with the case. 
Section IV is the case analysis in which theories pertinent 
to the case are discussed and the particular facts of the 
case are related to the theory. 

One specific area of analysis which will be included in 
all six cases is Nolan's Stages of Growth Model [Ref. ll:pp. 
672-673]. Nolan has researched information systems 
development throughout many organizations. His research 
involved the monitoring of information systems investments, 
information systems budgets, types of applications being 
developed, and the degree of management control and planning 
utilized. By looking at these factors he noticed definite 
shifts in the direction and gr^'wth of the information 
systems. He developed a model covering six stages of growth 
of both the information systems and the management of the 
information systems. Not every organization or information 
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system passes through all of these phases, but they are a 
good indication of possible directions for the future. This 
model can assist an information systems department to 
evaluate its present and future decisions in comparison with 
basic indicators of growth. See Figure 6. Throughout the 
case series, the stage or stages that NMPC-47 is in will be 
identified and discussed. [Ref. ll:pp. 672-673] 


Nolan's Stages of Growth Model 



TIME (experience in iniorrraiion systems aeveiopment ana usage) 


Figure 6. Nolan's Stages of Growth Model 
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B. CASE STUDY ONE TEACHING NOTE 


1. Questions 

What problems do you anticipate with the development 
and implementation of the management information 
system? 

What was done well in the development and 
implementation? 

What affects do you think implementation of the 
prototype will have on the Life Cycle Management of 
OAIS? 

2. Case Summary 

This part of the case series provides the background 
concerning the establishme i of the Officer Assignment 
Information System (OAIS). Descriptions of the users, user 
requirements, command mii. _on, and OAIS requirements are 
discussed. The development methodology chosen for OAIS 
development was prototyping. The software utilized was 
Application Productivity System (APS)COBOL, a third 
generation language. NMPC-47 was on the leading edge of 
technology by utilizing prototyping versus the traditional 
development approach. The initial deployment of OAIS, the 
problems encountered throughout the user organization, and 
the improvements OAIS made in a previously manual assignment 
process are described. 

3. Manor Issues/Problems 

Use of prototyping development methodology and a new 
generation of software. 

Deployment of the prototype due to user dependence. 

Poor documentation. 
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Lack of pre-implementation activities for the 
application and the effects on the users. 

4. Case Analysis 

a. Nolan's Stages of Growth 

Stage one is called Start Up. This stage begins 
with the first computer acquisition of an organization. In 
this stage the computer is being utilized for general and 
administrative projects whose automation would result in 
cost savings. There is quite a bit of change; change in 
jobs and working habits and fear of the unknown. [Ref. 
ll:p. 672] 

NMPC-47 has just entered the Start Up stage. 

The assignment process is one c' an administrative nature. 
The first computer has not even been procured and a leasing 
arrangement is providing the computing power. Personnel 
within the computer organization who are used to manual 
methods and potential users of the system are resisting the 
change and fearing the unknown. 

b. Prototyping Methodology 

Prototyping is a devel ■'ment methodology that 
enables the developer of a computer application to create a 
working model of the software to be built [Ref. 12:p. 22]. 
Prototyping is used in cases where the speed of implementa¬ 
tion of the computer application is of the essence and/or 
where the users are unable to specify explicitly what they 
want the system to do. Good potential computer application 
candidates for use of the prototyping methodology include: 
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those where the user is concerned about screen format, where 
the system will be on-line, where there are very few 
algorithmic details, and the system utilization is for ad 
hoc retrieval or record management [Ref. 13:p. 61]. The 
prototyping takes the place of requirements definition in 
the traditional classical project life cycle development 
methodology. 

The prototyping steps are as follows: (1) 

identify the user's known information requirements; (2) 
develop a working model; (3) have rhe users use the system 
in a "hand's on" manner and note user requests for changes; 
and (4) refine or expand user requirements through 
development of another model [Ref. ll:p. 612]. This process 
is iterative and continues until the user is satisfied with 
the working prototype. Not only does the user clarify his 
requirements for the computer application, but the developer 
of the system also receives a clearer picture of what needs 
to be done [Ref. 12:p. 23]. One problem that has been 
identified with prototyping is the tendency of users to 
accept a premature prototype. A major factor contributing 
to this is dissatisfaction with the current system [Ref. 
14:p. 2]. 

The assumption within the prototyping 
methodology is that once the users are satisfied with the 
prototype, the model will be thrown away and replaced with 
real programs by following the design, code, test and 
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implementation steps of the traditional development 
methodology [Ref. 13:p. 61]. The reasons for throwing away 
the working model are as follows: The emphasis of the 
prototyping method is on the output, not how the output is 
produced [Ref. ll:p. 612]. This emphasis on the output 
combined with the fact that the developer is working under a 
time constraint leads to the possibility of compromises in 
cne implementation of the inner workings of the model. Such 
things as error recovery, audit trails, backup/restart 
facilities, user and system documentation and conversion 
procedures may be glossed over [Ref. 13:p. 62]. An 
inefficient algorithm may be incorporated or an inappropri¬ 
ate operating system may be utilized all in the interest of 
time and output [Ref. 12:p. 23]. Factors which affect the 
life cycle of the computer system such as overall software 
quality, and long term maintainability may not be considered 
[Ref. 12:p. 23]. 

The decision to use the prototyping methodology 
at NMPC was an excellent one. Problems with the manual 
assignment process had been discussed for several years. Of 
particular significance was the amount of time it took to 
process an individual officer's assignment. Each assignment 
took approximately four to five weeks to get approval. The 
assignment then had to be manually costed and typed before 
transmission to the officer. Other problems included 
officer information existing in different files within 
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different computer systems in NMPC-16, accuracy of the data, 
inaccurate reporting instructions on moves, and inability to 
consider a large pool of possible assignments. Since the 
users were a diverse group, with the manual assignment 
process being adapted differently for each department 
(Aviation, Submarine, and Surface), NMPC-47 was unsure 
exactly what the user requirements were. Additionally, due 
to the timeframe of development, the early 1980's, problems 
with the traditional life cycle development were coming to 
light. Cost overruns, schedule delays, and computer systems 
not meeting user requirements characterized the current 
state of the industry. The prototype was developed and 
users from the Surface Department helped refine the working 
model. 

c. Selection of Software 

APSCOBOL, a product still under development, was 
chosen as the software for OAIS. The Application 
Productivity System portion consisted of an application 
generation tool which would interface well with the 
prototyping methodology. Application generators are 
software programs that permit specification of an entire 
application at a high level without having to be concerned 
with the coding of each line cf code. The application 
generator produces the source code based upon the 
specifications [Ref. ll:p. 254]. It can also allow a junior 
programmer to produce sophisticated code after just a few 
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weeks of training. Other tools included a screen painter 
and report generator. A screen painter allows easier 
configuration of a data formatted screen. Additional 
benefits are ease of change and proper spacing for ease of 
use. A report generator assists the extraction of data for 
reports from specific files. These tools can speed up the 
production of code. 

Of particular importance to NMPC and the 
prototyping methodology was the portability of APSCOBOL 
between different types of hardware. By using APSCOBOL, a 
prototype could be developed during the hardware procurement 
process with the knowledge that whatever hardware was 
purchased, the prototype would be able to function on it. 
There was definite risk taken by NMPC by using the first 
version of APSCOBOL. It is a notorious fact that the 
original version of most any piece of software contains bugs 
and it is safer to wait for the next version, where the bugs 
have been corrected. 

d. Deployment of the Prototype 

The prototype vastly improved the assignment 
process. Users became so dependent on the system that when 
it was time for the developers to take the working model and 
finish the rest of the development steps, NMPC-47 management 
gave into user pressure for immediate implementation of 
OAIS. 
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The tendency to implement the prototype is a 
strong and dangerous one [Ref. 13:p. 63]. Problems that 
this will cause cover both the immediate and long term life 
cycle management activities. Recall that prototype emphasis 
is on the output, not the internal workings of the system. 
Inefficient algorithms, error handling procedures, 
inadequate interfaces with other systems, and poor user 
documentation are a few of the possible immediate problems. 
In the long term, mainternnce and modification of the system 
will be difficult. Inefficient use of computer resources 
will come into play, incom^. lete system documentation will 
make incorporation of changes frustrating and the changes 
will take a longer period of time [Ref. 14:p. 2]. Of 
particular note are changes desired by the second generation 
of users [Ref. 13:p. 63]. Second generation users are those 
users not around to see the vast difference between the 
manual system and the automated system. Changes requested 
by these users will most likely be handled by second 
generation developers who are not as familiar with the code 
and appropriate reasons for handling certain situations as 
they are. 

To guard against implementation of the 
prototype, project management should state at the start of 
the project what the development procedures will be [Ref. 
14:p. 2]. By providing this guideline and educating the 
users as to the benefits of proper design, test and 
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implementation, a better computer system, in both the short 
and long term, is possible. 

Problems with implementation of the prototype 
first became evident as OAIS was implemented in the Aviation 
and Submarine Departments. The lack of user documentation 
caused OAIS utilization problems. Training is an integral 
part of the implementation procedures for a computer 
application. Users that are not prepared beforehand with 
training and user documentation are soon frustrated and 
often times do not use the application. There had been no 
problem with OAIS within the Surface Department due to their 
working knowledge of the system which was acquired during 
their assistance with development. A training officer 
billet was established and filled in the summer of 1984. 

The first user's manual was produced in January 1985, over 
two years after the implementation of the prototype, 
e. Poor Documentation 

One of the problems cau 1 by implementation of 
the prototype is the poor quality or lack of documentation. 
The following has been noted from ? report prepared by 
SYSCON corporation concerning documentation efforts in 
prototyping efforts: 

...formal written documentation takes a poor second to the 
exciting, more visual simulation of new prototype 
software. Often, by the time it is understood how badly 
good, careful documentation is needed, the people who 
could write it best are gone. [Ref. 15:p. 5] 

Without documented requirements, interpretation replaces 
detailed definition. Developers interpret users' stated 
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requirements. Subsequent modification to functionality is 
interpreted by new users' in relation to the operating 
software system. The process moves ever further from 
objective to subjective. [Ref. 15;p. 5] 

The lack of user documentation and its effects 
have already been discussed. Modifications and enhancements 
have not occurred to OAIS yet, but it is fairly safe to • 
predict that problems will occur due to a lack of system 
documentation and updated system requirements. 

f. Suggested Pre-Implementation Activities 

Any change within an organization needs to be 
planned for and managed closely. Individuals resist change 
for a variety of reasons. These reasons include fear of the 
unknown, avoidance of uncertainty, additional pressures and 
loss of individual security [Ref. 9:p. 37]. Past ways of 
doing business, daily habits and routines are a part of an 
individual's security because they are predictable. There 
is a loss ot Che prior "comfort zone," which contributes to 
an individual's sense of values and view of themselves [Ref. 
9: p. 163]. 

Two criteria are recommended for minimizing 
resistance to change. These are education of personnel and 
user participation in the planning and decision process 
[Ref. 16:pp. 94-95]. Education of personnel establishes 
effective lines of communication and decreases speculation 
and rumors. The longer personnel have to speculate about an 
upcoming change, without being provided official 
information, the more likely it is that resistance will 
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emerge [Ref. 9:p. 163]. Having open lines of communication 
gives personnel someone to go to with questions and 
concerns. Education provided to individuals should include 
schedules, plans, both short and long term, and their 
probable consequences [Ref. 16:pp. 94-95]. 

It is more likely that acceptance of the change, 
as well as an assurance of the application meeting user 
needs, will be accomplished by involving personnel in the 
planning process. Personnel that are involved are more 
likely to display interest and feel a sense of ownership. 
This is likely to lead to increased motivation and 
understanding [Ref. 9:p. 163]. Additionally, in a sense, 
management has added people to its point of view for the 
need and understanding for change. Personnel involved with 
the change can spread good information, not rumor, among 
fellow workers. 

In addition to education of users, all levels of 
management should be made aware of the upcoming changes 
[Ref. 16:p. 132]. This awareness will increase both support 
of the new idea and perhaps bring out possible loopholes 
missed up to this point. With all m.anagement levels 
speaking the party line and understanding the reasons for 
change, increased acceptance will be the benefit. 

An organization is composed of flows of 
information, personnel and material [Ref. 9:p. 29]. The 
implementation of OAIS affected all three of these factors. 
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The flow of information went from manual to automated. The 


personnel interacted with throughout the course of a 
business day changed as well as how the material was 
produced. Different material was also produced. Automated 
reports, one of the outputs of OAIS, were now sources of 
information. 

Taking into consideration the two criteria 
useful in minimizing resistance to change; there was 
participation of some users (all from the Surface 
Department) in the decision making and modeling of the 
prototype, but no education of current or future users. 

This participation in the prototyping process did foster a 
sense of ownership and additional motivation within the 
users. Training was not necessary for these personnel. 

This first implementation in the Surface Department set a 
bad precedent for NMPC-47 management and created a false 
sense of security. 

It was not until basic problems with using OAIS 
were discovered upon subsequent implementations that 
management realized education of users was a necessity. In 
addition, the lack of education for the personnel in the 
Information Systems Support branch and Order Support branch 
concerning the department's changing direction was a 
deterrent to acceptance of change. Information Systems 
Support branch personnel were busy maintaining the current 
manually-oriented systems. They were not consulted on the 
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details of the new systems, nor invited to meetings. These 
were the people familiar with the systems which would 
interface with OAIS as well as those with the intimate 
knowledge on order writing, the primary objective of OAIS. 
Without their support and indeed the criticism they heaped 
on OAIS, the resistance of the users who still interfaced 
with these personnel grew. 

After implementation of OAIS, many users 
continued in their manual-oriented routine patterns of 
decision making, order verification and interface with 
personnel in the assignment process chop chain. If top 
management within the division such as the Submarine 
Department, took an active interest, it was more likely that 
OAIS use replaced some manual work. One user had not even 
turned the computer on. It was not until individual 
attention was paid to each person or group, that grudging 
acceptance came. "Tender loving care" was called for to get 
past the resistance and onto understanding and comfort with 
OAIS. This was accomplished by establishment of a training 
officer billet. Establishment of this function was a 
reaction instead of a planned event. If training of users 
had been planned upfront along with the software development 
and hardware procurement, OAIS acceptance would have 
happened much quicker within the command. 
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C. CASE STUDY TWO TEACHING NOTE 

1. Questions 

Does project management work well with this 
organization structure? Why or why not? What changes 
would you recommend? 

Are you satisfied with LT Hopkins' management of the 
OAIS project? 

Is the new version of OAIS going to work properly? Why 
or why not? 

2. Case Summary 

This case addresses the timeframe of October 1985 
through May 1986 for acti\ ‘:ies within NMPC-47. A new 
project officer for OAIS has just taken over the project. 
Personnel changes are al' ' taking place within the 
contractor's OAIS project staff. The primary activity 
during this time is development of a new version of OAIS. 

The major changes involved are conversion of the software 
from the original version of APSCOBOL to a new version, 1.7, 
and a newly designed orderwriting module. The team of 
personnel responsible for tnis new version is a combination 
of contractor and Navy Data Processing Technicians. 

3. Major Issues/Problems 

Implementation of matrix structure on organization. 

New project officer and project officer style of 
management. 

Heavy reliance on contractors. 

OAIS development team combination of contractor and 
Navy personnel. 

Lack of planning for pre-implementation activities. 
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4. Case Analysis 

a. Nolan's Stages of Growth 

NMPC-47 has moved up the growth curve with its 
evolving computer application. The changes to OAIS put NMPC 
in the Growth of Information Systems stage. Characteristics 
of this stage are having the excess computer capacity 
characteristic of the Start Lp pnase being used up quickly, 
and making investments in additional hardware and software. 
This contagious enthusiasm of users and computer personnel 
results in uncontrolled growth. OAIS users have become 
somewhat sophisticated in usage of the application and have 
requested enhancements. The Systems Administration division 
has just received its first computer and additional 
peripheral equipment is on the way. [Ref. ll:pp. 672-673] 

b. Project Management 

Project Management is ar ongoing process 
throughout the life cycle of a computer application by which 
a team leader (project officer) directs the team in the 
development of an acceptable systen ^hich meets user 
requirements and that is produced within the allotted time 
and budget constraints [Ref. 17:p. 161]. Directing the team 
involves using the basic management functions of planning, 
organizing, directing and controlling. The key concept 
underlying project management is that the project officer is 
the single point of integrative responsibility between all 
project team members [Ref. 18;p. 4]. 
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In the OAIS project, the development team would 
consist of the contractors, the Navy Data Processing 
Technicians in the Application Programming Shop, the 
Training Officer in N470, and the various functional 
managers such as Systems Administration, Data Administration 
and Configuration Management. The integration of all of 
these faction's efforts towards development of a new version 
of OAIS is LT Hopkins' primary task. 

Project Officers' view project management as "a 
source of considerable frustration in attempting to execute 
their responsibilities in the face of inadequate authority, 
misunderstanding, skepticism and even hostile attitudes." 
[Ref. 18:p. 17] Frustration results from having to 
coordinate various activities with personnel on several 
levels within the organization and needing to give effective 
direction to personnel that do not report to them in the 
formal chain of command [Ref. 18:p. 34]. Within NMPC-47, 
project management operates in an organization structured as 
a matrix. Resources and taskings go across traditional 
organizational lines and the personnel tasked are working 
for two bosses, LT Hopkins, the project officer and their 
functional manager. 

c. Matrix Management 

Using a matrix structure is the preferred 
arrangement when the following three basic conditions exist 
simultaneously within an organization: (1) outside pressure 
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for dual focus; (2) pressures for high information 
processing capacity; and (3) pressures for shared resources. 
A dual focus refers to a situation where two issues are 
critical to the organization's survival. In the case of 
NMPC-47, the dual focus is for development of OAIS and the 
continued manual maintenance of functions required by 
assignment and placement personnel. Neither function can be 
allowed to overrule the other as they are both critical to 
the continued fulfillment of the organization's mission. A 
balance of power must be maintained between the two areas 
and each issue must be addressed during decision making 
especially decisions dealing with costs, schedules, and 
personnel. Having pressures for a high information 
processing capacity are the result of relatively unstable 
and unpredictable demands on the organization. This 
unstable condition dictates the need for additional 
information processing. The unstable condition in 
conjunction with unknown future events, such as 
technological advances, environmental rulings and government 
regulations, requires consultation with many members in the 
organization. These additional personnel involved in 
decisions increase the complexity of the decision making and 
increase the requirement for additional information 
processing. NMPC-47 is in an unstable condition. OAIS has 
been developed by contractors and implemented for 330 users. 
The Information Systems Support branch, N471, has just 
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received its first computer and OAIS has transferred from 
the leased machine to the hardware in-house. The first 
major change to OAIS, software conversion and enhancement to 
the orderwriting module, is underway. NMPC-47 is dealing 
with changes in technology as well as supporting 330 OAIS 
users and implementing a major change. The expertise of 
many personnel located throughout the department is needed 
in the decision making process to ensure the continued 
smooth operation of OAIS and the development of the OAIS 
enhancement. The third condition for a matrix structure is 
pressures for shared resources. By sharing resources, 
economies of scale are achieved, scarce resources are 
available and costs can be decreased. For NMPC-47, the 
resources consist of human and computer resources. Of 
particular concern are the technically proficient personnel 
in the Information Systems Support branch, whose expertise 
is needed for assistance with the OAIS enhancement. The 
expertise of the Order Support branch personnel concerning 
the requirements of officer orders is also needed during the 
design of the orderwriting module. [Ref. 19:pp. 13-18] 

There are advantages and disadvantages to a 
matrix structure. Besides assisting with the above three 
conditions, a matrix structure can also create 
opportunities. There is the opportunity for growth in 
individual knowledge and skills that is not possible in the 
traditional organization structure [Ref. 19:p. 103]. With 


106 






the increase in complexity and personnel involved in 
decision making comes increased amounts and patterns of 
contact between individuals [Ref, I9:p. 104], This 
increased contact increases the requirement for 
communication. Communicating with the necessary personnel 
takes additional time and enhanced communication skills. 
Conflicts between individuals are certain to arise. 

Conflicts can be looked at from a positive viewpoint. If 
all the personnel involved in a conflict air their opinions 
and the assumption is that everyone is working for the 
common good of the project, then it may be possible to 
arrive at the best solution to a problem [Ref. 19:p. 104]. 

A decision can not just be made one day to 
transition to a matrix structure and the next day do it and 
achieve success. The process of the transition doesn't just 
involve changes to the organization chart. Changes are also 
required in the systems, culture and behavioral patterns of 
the personnel involved. The success of a matrix is 
dependent on the organization helping the personnel to 
understand and function in new ways [Ref. 19:p. 103]. For 
the most part, people are brought up in the "one person-one 
boss" tradition. Switching over to being responsible to two 
bosses often involves stress and uncertainty due to the 
possibilities of conflicting interests and loyalty to 
functional responsibilities [Ref. 19:p. 18]. 
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■ n 

In this case study, NMPC-47 had just made the 
switch to the matrix structure. The time was not taken to 
educate personnel, management or to prepare the organization 
for the change. Development concerns had top priority. A 
matrix organization for accomplishment of OAIS project 
management was the means to the end. If the time had been 
taken to educate those involved, establish procedures and 
standards, many of the problems, primarily those concerning 
conflicts, could have been diminished. Conflicts in 
computer system project me agement can be generated from the 
following: project priorities, administrative procedures, 

technical opinions, perf^-raance trade-off decisions, 
utilization of manpower resources, cost, schedules, 
personality and intensity of work required according to the 
phase of the life cycle that the project is in [Ref. 18:p. 

46] . 

Conflict can be minimized by the managerial 
behavior of the project officer. Managerial behavior 
concerns approaching functional managers with flexibility, 
understanding of both sides of an issue and by avoiding 
absolute statements of requirements [Ref. 19:p. 51]. 

Project officers must rely heavily upon their interpersonal, 
group management, and communication skills to influence 
people to do what is essential for project success. When 
project officers are dealing with their peers within an 
organization, Stanley Davis and Paul Lawrence suggest that 
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they determine how the other person operates and with this 
knowledge establish an individual relationship with each of 
the different personnel on the project [Ref. 19:p. 88]. 

In particular, for development of a computer 
application, the three areas most likely to cause conflicts 
are priorities, manpower resources and schedules [Ref. 18:p. 
53]. Each of the functional managers has his/her own 
schedules, priorities and workload which must be fulfilled. 
It is a given that the original plans and schedule will 
change as the project is developed. Each computer project 
will be different, will be developed by a different team of 
personnel and, in particular, the unexpected can occur when 
dealing with new technology. By keeping personnel involved 
with the project as up to date as possible, the project 
officer can lessen the surprises and crisis situations which 
lead to conflicts. 

In addition to managerial behavior, the 
establishment of interpersonal influ.-.ice bases are helpful 
to a project officer in performing his/her job. Three 
influence bases suggested by Russell D. Archibald are; (1) 
reward and punishment power; (2) exp'" rt power; and (3) 
referent power. Reward and punishment power involves having 
the power to either block or facilitate the attainment of 
personnel or career goals of the people working on the 
project. Expert power refers to the expertise of the 
project officer concerning the specific topic or project. 
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Expert power is conferred on the project officer if the 

personnel feel he/she has greater expertise than they do in 

the subject matter or that he/she is more qualified to make 

decisions than they. Referent power is when the personnel 

are personally attracted to the project officer and value 

that relationship and the project officer's opinion of them. 

Personal friendships and alliances can become an important 
source of influence for a project manager. If a project 
manager is personally disliked, he many have negative 
referent power, which will make the task of influencing 
the project contributors even more difficult. [Ref. 

18:pp. 45, 44-45] 

d. LT Hopkins' Management 

LT Hopkins did not integrate the efforts of the 
project team members in the project. Functional managers 
and team personnel continued on with their functional 
responsibilities, but there was no team effort working on 
making the OAIS project a success. For example, personnel 
in the Information Systems Support branch, N471, where the 
Systems Administration and Configuration Management 
functions are located, were not invited to meetings nor 
consulted or apprised of OAIS plans. The Training Officer 
was also not involved in the development of OAIS. Changes 
being made to OAIS were of particular importance to the 
Training Officer, but this information was not available 
until a month before implementation of the new system. The 
most significant lack of coordination occurred with the 
combination Navy and contractor programmer team. The two 
groups were working on separate portions of OAIS, 
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orderwriting and software conversion respectively, but 
coordination of their progress, scheduling of computer time, 
and planning for the eventual combination of their two 
programs was not done. 

LT Hopkins was a new project officer and many 
knowledgeable personnel had left the OAIS project, but that 
does not excuse her disregard for acceptable managerial 
behavior. Cooperation with LT Hopkins may have been more 
forthcoming if she had approached the functional managers in 
N471 first as a courtesy measure in regards to tasking their 
manpower or need for a schedule change. LT Hopkins did not 
have good interpersonal relationships with the functional 
managers. Her aggressive manner and "I want it done now” 
attitude contributed to the problem. Thus, she reduced her 
effectiveness and was not able to build a power base from 
which to launch the project. Assistance was available if 
she had only asked for it from her peers responsible for 
portions of functional management. In particular, CDR Hazel 
was an acknowledged functional expert on OAIS. The ability 
to build an expert power base by becoming an functional 
expert on the OAIS system was available to LT Hopkins. She 
did not make an effort to acquire the knowledge. If she 
had, in addition to building her expert power base, she 
would have been able to ask some intelligent questions 
throughout the OAIS development process. From this she may 
have been able to identify some of the problems prior to 
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implementation. The third power base, that of reward and 
punishment power, was not available to LT Hopkins due to the 
inadequate implementation of the matrix structure in the 
organization. Personnel affected by the two boss situation 
did not view tasking by LT Hopkins on the same level as 
tasking by their functional boss. 

There are several factors which may have 
contributed to LT Hopkin's poor performance as a project 
officer. One factor was the mindset of the project officers 
in regard to the contractor. The mindset was, "We are 
paying big bucks for a quality product." Therefore, LT 
Hopkins did not have any indication that more involvement 
with the contractor was necessary than that of her 
predecessor. In the history of OAIS, the contractors had 
been taken at their word concerning all aspects of systems 
development and production. The contractors had not been 
wrong yet, which was one of the reasons that the OAIS 
reputation was good with both users and management. 

However, when LT Hopkins reported aboard, NMPC-47's project 
officer and the project manager for the contractor both 
left. This left just a handful of personnel familiar with 
OAIS functions and history involved with the project. 
Additionally, with OAIS documentation of poor quality, there 
were no references to turn to for assistance with problem 
solving. Lastly, previous development efforts and project 
managers did not have to contend with relationships with 
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training, systems administration or configuration 
management. These functions had not existed then. This may 
explain some of the lack of inclusion of Infoirmation Systems 
Support branch personnel in OAIS planning, 
e. Pre-Implementation Problems 

Pre-implementation activities typically involve 
the testing of the program, and training for users and 
operators. Testing of the program can be broken down into 
four types of testing. There is individual module testing 
or unit testing, to ensure that the internal workings of the 
module, the data structures, error handling routines, and 
the input and output parameters work properly. Next is 
integration testing. This is where all the individual 
modules are combined and tested for proper interfaces and 
data passing and their ability to work together. The third 
test is a system test. This test includes all the factors 
that make up a system, the hardware, software, peripheral 
equipment, people and procedures. This test is to ensure 
that all factors work together and perform their allocated 
function. The fourth test is validation of the system. 
Validation is a check to ensure that the customers' original 
requirements of what the system is supposed to do are 
fulfilled. The second major pre-implementation activity is 
user and operator training. User training consists of two 
parts—provision of formal user documentation on how the 
system works and "hands-on" training. "Hands-on" training 
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is the actual usage of the computer application. Users 
become familiar with both the computer itself and the 
application implemented on the computer. Users that are 
trained before implementation are much more likely to accept 
the new system and be less frustrated when things go wrong. 
Operator training is the training of the production control 
and scheduling personnel concerning new procedures for 
running batch jobs. Having operators familiar with new job 
control language, sequencing of jobs and indicators of 
smooth running operations is essential for successful 
implementation of the new application. 

During preparation for the implementation of 
OAIS, some training and some testing were completed. User 
training was conducted in a conference room with the new 
user documentation. "Hands-on” training was not a viable 
option due to the lack of a training facility and test 
computer application. Individual testing was done on the 
modules. This testing was done in the evening due to the 
lack of a testing facility on the computer. Integration, 
system and validation testing did not take place. Before 
OAIS came up, there had never been a complete run-through of 
the whole application or system nor validation of what the 
application was supposed to do for the users, 
f. Development Team 

The programming team for development of the OAIS 
conversion and orderwriting module consisted of two groups. 
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One group was the contractors and their main job was 
conversion of the APSCOBOL code from version JK to version 
1.7. The other group, made up of Navy Data Processing 
Technicians (DP's), was responsible for coding the newly 
designed orderwriting module. For the most part, the DP's 
were experienced programmers. There was a reason behind 
this integrated programming team. The reason was that 
maintenance of OAIS would be the Navy's responsibility once 
this version of OAIS was implemented. By having the DP's 
participate in the prograr. ing, they would gain some 
valuable experience with the language. Unfortunately, there 
was no coordination amonc the programming teams. For the 
most part each worked in isolation. The code the 
contractor's were converting would be interfacing with the 
new orderwriting module in several situations. The two 
would be passing data for order generation over an interface 
as well as creating batch reports. The lack of testing is 
unexcusable. 

D. CASE STUDY THREE TEACHING NOTE 
1. Questions 

What accounts for the failure of OAIS? 

What does CDR Griffin mean when he says "project office 
people always seem to forget the production portion of 
this business"? 

If you were LT Hopkins, what would you do when the new 
version is taken out of production? 
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2. Case Summary 

This case study covers the timeframe immediately 
following the implementation of the new version of OAIS. 

The attitude and thoughts of NMPC-47 management are 
described. Reactions to the failure, and procedures to 
guard against problems happening in the future are 
addressed. A major manpower cut by OP-01 causes a change to 
the maintenance plans and contract management for OAIS. 

3. Major Issues/Problems 

Project Management in a poorly implemented matrix 

structured organization. 

Lack of testing. 

Lack of concern for production issues. 

LT Hopkins's actions. 

4. Case Analysis 

a. Causes of OAIS failure 

(1) Project Management . Russell Archibald 
states that the following six causes are the reasons for the 
poor performance on projects [Ref. 18:p. 10]; 

Poor understanding of the project manager job. 

Wrong type of person assigned as project manager. 

Excessive conflict between project and functional 

managers. 

No integrated planning and control. 

- Rapidly changing and conflicting project priorities. 

Improperly organized and staffed project offices. 


116 






The first four of these causes apply to the OAIS failure. 
These four problems can be attributed to the poor 
introduction of the matrix structure for OAIS project 
management in NMPC-47. Without education of personnel 
involved in the change to a matrix structure and the 
subsequent change to procedures, and behaviors, there will 
be a poor understanding of the project manager job. 

Personnel tasked by LT Hopkins did not feel that her tasking 
was of equal importance as tasking from their functional 
managers. Being a project manager requires competence in 
working with people, force of personality and skills in 
group management [Ref. 19:p. 87], By choosing a project 
manager who lacks these skills and relationships, the job is 
put in jeopardy of failing. Influencing functional managers 
and negotiating for the success of the project are a large 
part of the job. LT Hopkins lacked the interpersonal skills 
necessary to both motivate people and to facilitate project 
tasking. In particular for NMPC-47, by LT Hopkins lacking 
these skills, the problems inherent from the incomplete 
introduction of the matrix structure in the organization 
were magnified. These problems were evident in the 
excessive conflict between the functional managers and the 
project officer. LT Hopkins resorted to an aggressive style 
and by issuing absolute statements. The mandating of 
absolutes is a condition that Stanley Davis and Paul 
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Lawrence state is detrimental to working within the matrix 
structure. 

The lack of integrated planning and control 
of the project development team is the underlying reason for 
the failure. This lack of integrated planning and control 
is particularly evident in the lack of coordination between 
the two different parts of the programming team. This lack 
of control led to a lack of integration and systems testing 
which ultimately caused OAIS to fail. The lack of 
integrative planning and control was also evidenced by not 
including Information Systems Support branch personnel in 
OAIS development planning. With the inclusion of all 
personnel whose expertise is needed to assist with the 
development of OAIS, a lot of problems could have been 
identified earlier in the project development. 

(2) Lack of Testing . The primary cause, on the 
surface, of the OAIS failure, was the degraded systems 
performance caused by the converted code. The system slowed 
response time for user requests. This situation was allowed 
to continue for two days until user complaints were so 
numerous that top management could not ignore them. The 
users had become dependent on OAIS for production of their 
everyday work. They were unable to do their jobs for two 
days. When the new version of OAIS was taken down, there 
was another day of computer unavailability. A total of 
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three days were lost, an unnecessary consequence due to a 
lack of testing prior to implementation. 


(3) Organization Inexperience . NMPC-47 is 
relatively new in the automated data processing business. 

In addition to project officer problems and poor matrix 
introduction to the organization, NMPC-47 is making mistakes 
because of inexperience. The contractors, who had 
implemented the original version of OAIS did not see the 
need for more testing of the application. NMPC-47 had not 
had to question the contractor previously and did not know 
any differently. 

b. Lack of Concern for Production Issues 

CDR Griffin's comment concerning how the project 
office people always seem to forget the production side of 
the business can be construed to indicate a lack of integra¬ 
tion. CDR Griffin's comment acknowledges the management 
emphasis in NMPC-47, both past and present, which is on 
development. With over 300 users dependent on OAIS, 
maintaining production OAIS should have been of equal 
importance to enhancement of the application. To ensure 
proper addressing of production issues, N471 personnel 
should have been included in OAIS plans and decision making. 

c. LT Hopkins Management Changes 

LT Hopkins advocated two changes to the 
management of the OAIS application. She wanted OAIS 
modularized into smaller portions and test plans to be drawn 
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up for each screen, module, program and interface of OAIS. 
These two changes were good decisions. 

Having OAIS broken down into smaller modules 
will facilitate testing, detection and correction of errors. 
Error detection and correction is made easier as the code 
that needs to be debugged is localized instead of being 
spread through out the program. Also by having a smaller 
portion of code to test, programs can be debugged more 
thoroughly [Ref. 20:p. 131]. Modularization also provides 
for the evolvability of the software [Ref. ll:p. 697]. If a 
change needs to be made, the module can be coded and 
inserted in the program with a minimum of effort and changes 
to other interfacing modules. 

By mandating test plans for each screen, module, 
program and interface, there will be assurance that 
integrative and validation testing have been performed. 
Additionally, having the users involved in conducting the 
test plans will increase their confidence in the new system 
and assist with their training on changes contained in the 
new version. 

One recommended change, that of having one group 
in control and responsible for the programming phase, was 
taken care of by the manpower cuts. This manpower cut laid 
the framework of the future for NMPC-47. NMPC-47 will now 
be dependent on contractors for development and maintenance 
of their computer applications. This change affected the 
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management of the entire life cycle, in particular adding 
additional costs for contractor resources to ensure the 
continued operation of OAIS. An additional recommendation 
is that if LT Hopkins continues her mode of operation of 
being the sole interface with the contractor, she should 
become more of a functional expert on OAIS and user 
requirements. 

E. CASE STUDY FOUR TEACHING NOTE 

1. Questions 

What are indicators c maturity in NMPC-47? 

What is the structure of the IS organization? 

Will the OAIS imple; ■ itation be a success? 

2. Case Summary 

This case study describes the activities of NMPC-47 
during the time period of May 1986 through May 1987. The 
primary activity taking place is the redevelopment of a new 
version of OAIS. Changes within tl' organization include 
transition from a development-oriented department to a 
production-oriented department wit an emphasis on customer 
support. OAIS usage has increased. There are more 
terminals available than there are ports on the bus 
interface units connected to the local area network. OAIS 
users have become more comfortable with OAIS and in une 
process discovered unprotected data fields and ways to use 
OAIS information and screens that were not intended. 

Lessons learned from the implementation in May 1986 of OAIS 
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are applied to this implementation effort. A systems stress 
test is planned and executed. Test Plans are used for 
integration and validation tests. 

3. Major Issues/Problems 

Maturity of OAIS. 

Centralization of computing resources. 

User sophistication. 

IS organization transition. 

Incorporation of lessons learned in May 86 

implementation. 

Pre-implementation activities. 

4. Case Analysis 

a. Nolan's Stages of Growth 

NMPC-47 displays characteristics of both the 
third and fourth stages of Nolan's Stages of Growth. The 
third stage is called Formalizing Control. Characteristics 
of this phase that NMPC-47 is exhibiting are growing pains 
towards maturity, some centralization of resources and 
equipment and an emphasis on processes instead of products. 
The growing pains and emphasis on processes is evidenced by 
the transition from a development-oriented department to a 
production-oriented department. A process of customer 
support has developed and it resulted from the consolidation 
of several separate products such as hardware repair, error 
research and report generation. The fourth stage is called 
Realignment and Integration of Processes. Characteristics 
of this stage that apply to NMPC-47 include user 
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sophistication and stability of operations. [Ref. ll:pp. 
673-674] 

(1) OAIS Maturity . The recognition of the 
usefulness of OAIS information has grown. Requests for 
access to OAIS are received from other commands. OAIS is 
not viewed as just facilitating the lives of assignment and 
placement officers within NMPC, but as being important to 
personnel planning activities external to NMPC. Recognition 
of the importance of OAIS information has personnel within 
NMPC competing for access to the application. There are 
more terminals than there are bus interface units on the 
local area network. Primary and secondary users are 
designated and specific ports are assigned to primary users. 
Competition for ports has caused port pirating. 

Considerable administrative time is spent solving the port 
pirate problems of users phoning the OAIS Help Desk. 

Assignment and placement officers had 
relied on OAIS for quite some time. Now user top management 
is also depending on OAIS generated information to do their 
job. In recognition of the increasing reliance on OAIS, 

OAIS Help Desk personnel were required to inform NMPC-47 top 
management, and the Admiral in NMPC-4, whenever there was a 
major problem with OAIS. Also, CDR Griffin established the 
NMPDS Crisis Management Team. The make-up of the team, 
technic-1 personnel from N471, was a statement supporting 
the production-orientation of the branch. 
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(2) Centralization of Resources . Computer 


operations are fairly stable. There are time and resources 
available to address production-oriented issues such as 
security, and customer support. A new security system is 
implemented, a test OAIS application is implemented and a 
dial-up capability for OAIS users out in the field is 
implemented. 

The implementation of the new security 
system, in essence a shell surrounding the entire NMPDS 
application, is also evidence of planning for the future 
integration of the four applications within NMPDS. The need 
for a test application was evident during the previous 
implementation attempt. It is available now due to the 
availability of additional computer resources and a planning 
for the future of OAIS within the command. The dial-up 
capability is an enhancement to the customer support 
process. The customer support process is also enhanced with 
the consolidation of all user support functions into the 
OAIS Help Desk. Previously the separate products of error 
research, hardware repair and OAIS status information were 
handled by separate divisions within N471. With the 
consolidation of all user support resources into a central 
agency, the customer is served more efficiently and 
effectively. 

(3) User Sophistication . OAIS users are very 
comfortable with the system. With this comfort comes 
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exploration (hacking) of the program. Unprotected data 
fields are discovered, screens are used for purposes for 
which they were not intended and information contained 
within the system is used for personal benefit. Examples of 
these unintentional uses are the Aviator's use of a screen 
for their internal phone list that was originally designed 
for the Submarine Department, and the review of personal 
information on doctors and lawyers before using their 
services. 

With user sophistication and additional 
computer resources, application development has been 
enhanced. This has resulted in increased usage of the On¬ 
line Adhoc Information System (GDIS) and electronic mail 
applications. GDIS is a database system which users may 
access with a little training on boolean algebra. GDIS 
provides reports and information in a customized format, and 
a query capability. The current use of electronic mail is 
sporadic across the Distribution Division, but several 
departments have started relying on it for internal 
messages. 

b. Information Systems Department Structure 
There are three primary functions that are 
typically performed by a Information Systems department. 
These are development, maintenance and production control. 
Development is concerned with the analysis, design, 
programming, testing, documentation, project management and 


125 







implementation of new applications. Maintenance is 
concerned with the continued operation of current 
applications. Production control deals with the processing 
of daily operations, such as updates, report generation and 
output, which are necessary for the continued viability of 
the computer applications. Two support functions are also 
necessary within an Information Systems department: 
administrative and technical support. The administrative 
function deals with planning, budgeting and personnel. The 
technical support function addresses systems programming, 
communications control, system monitoring, technical 
assistance, user assistance and data processing standards. 
[Ref. 21:p. 90] 

The Information Systems department, NMPC-47, 
transitions from a development-oriented to a production- 
oriented organization. As an information systems departmient 
matures, its operations become more important. This 
importance is due to the resources, in the form of 
personnel, equipment and software, which are needed for the 
continued support of computer systems in the organization. 
Once an application has been implemented and integrated into 
the operational routine of the organization, it cannot be 
discarded nor changed drastically due to user dependence. 
[Ref. 20:p. 46] 

Prior to this transition, N470, the Information 
Systems Development branch, was responsible for management 
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of all three primary functions and parts of both support 
functions. This was accomplished through a matrix 
structure. Development was handled through contractors with 
liaison between the contractors and the Navy in the form of 
a project officer in N470. Maintenance was accomplished by 
the Application Programming Shop in N470, while the need for 
the maintenance was determined in N471 and N472. Project 
officers in N470 determined production control priorities 
while the personnel doing the production control work were 
located in N471. Refer to Figure 3 in Case Study Two. 

This matrix ma. agement caused conflicts over 
work priorities, chain of command, and usage of personnel 
resources. Whenever there was a problem with production 
OAIS, LT Perkins at the OAIS Help Desk had to consult with 
LT Hopkins. In addition to wasting time, LT Hopkins was not 
fully aware of the impact of certain production problems on 
the users of OAIS. CDR Griffin and cDR Kice, oranch heads 
for N471 and N470 respectively, also had conflicts over 
allocation of resources and develot -.ent versus production 
priorities. With the priorities of the project management 
personnel taking precedence over those of production and 
technical support, both system readiness and the morale of 
personnel was low. 

Once the transition of responsibility for 
production decisions was made from N470 to N471, the 
responsibility for the three primary functions and two 
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secondary functions was more evenly divided between the two 
departments. Refer to Figure 4 in Case Study Four. The 
Information Systems Development branch, N470, continued to 
have responsibility for application development. Their 
responsibility for maintenance was a temporary requirement 
until the new version of OAIS was implemented. The 
Information Systems Development branch, N470, had 
responsibility for only one support function, the 
administrative function. Systems Administration in N471 
took over full responsibility for the production control 
function and some of the technical support functions such as 
systems programming, systems performance monitoring and 
configuration. Other technical support activities were 
handled by Configuration Management and the OAIS Help Desk. 
Configuration Management was responsible for technical 
assistance and data processing standards. The OAIS Help 
Desk, Training and personnel in N472 were responsible for 
user assistance. 

Customer service is one of six critical areas 
needing management control to ensure continued efficiency 
and effectiveness of the computer systems [Ref. 20:p. 62]. 
Afterall, the computer system is for the users. The move of 
the training function from N470 to N471 and the 
consolidation of responsibility for all customer contact 
into the OAIS Help Desk facilitated the development of a 
total customer service concept. The main idea was to 
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provide one-stop shopping for the users. Prior to this 
consolidation, users had to call Error Research if they had 
a problem with officer orders, or call Systems 
Administration if there was a problem with the computer 
hardware or a printer, or call Production Control if there 
was problem with receipt of a report. CDR Griffin 
recognized the need of having one organization responsible 
for interface with the users. This consolidation ensured 
quicker and better service to the user. The OAIS Help Desk 
also assisted in achieving better communications with the 
users. Personnel at the OAIS Help Desk called each 
department's user representative to pass along important 
information concerning an OAIS problem or computer downtime. 

A logbook to log all phone calls into the OAIS 
Help Desk was established. If a problem was called in 
concerning a hardware problem or report problem, a trouble 
report was sent to the appropriate part of N471 for 
correction. The time was logged and if feedback was not 
received at the OAIS Help Desk within a reasonable amount of 
time from the appropriate section of N471 responsible for 
the correction, follow-up action was taken. This audit 
trail ensured that a user's problem would not be overlooked. 
Additionally, the logbook provided a composite of user 
problems. From this consolidation it was possible to spot 
trends- concerning problem prone hardware or frequency of 
errors. 
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The change of the organization focus to 
production issues and customer support brought about changes 
to the jobs that the Data Processing Technicians (DP's) had 
been performing in NMPC-47. Most DP's want to program. 

Most programmers have a job orientation towards systems 
development, even though the majority of the work is 
production and maintenance oriented [Ref. 22:p. 9]. The 
DP's experienced the maturity of the organization by seeing 
it progress from an organization where the focus was 
computers and programming to an organization where the user 
and user desires were of utmost importance. The DP's that 
worked on the OAIS Help Desk resented being put in the 
position of answering the phone and dealing with frustrated 
users. The glamourous positions in their eyes were those of 
Systems Administration and the Information Center in N470. 
One factor that may have assisted in facilitating this 
change in direction in the organization would have been 
clear-cut, mappe:-out career paths for the DP's. Employees 
are motivated when there is a clearly-defined relation 
between performance, recognition and advancement [Ref. 23:p. 
42]. Instead of having advancement and transfer up to the 
discretion of top management, with their decisions based 
upon past performance cf personnel, designated career paths 
should have been established. When career paths are 
documented, personnel are motivated, recruited and trained 
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in accordance with their desires for promotion [Ref. 23:p. 
41] . 

c. Pre-Implementation Activities 

(1) Lessons Learned . One of the major problems 
identified with the implementation of OAIS in May 1986 was 
the lack of testing. In May 1986 there had been no 
integrative, system, nor validation testing conducted. All 
four types of testing were conducted for this implementation 
effort. One of the reasons for the lack of testing was lack 
of a test application. A test application was available for 
this implementation effort. Also, in the previous implemen¬ 
tation, the programming team was a combination of Navy Data 
Processing Technicians and contractor personnel. Having two 
groups responsible for the programming required a lot of 
coordination and planning. For this implementation, all 
programming was done by the contractors. After the failure 
of the OAIS implementation in May 1986, LT Hopkins said she 
wanted test plans made up for every screen, program, and 
module of OAIS. These test plans were created by the 
contractor and reviewed by appropriate Navy personnel. 

(2) Testing . A system stress test was 
scheduled for a Friday afternoon in February. An 
insufficient number of users participated for NMPC-47 to be 
sure how the system would react when a full load of users 
were using the system. Due to the Information Systems 
department being on the same level as the users in the 
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organization, CAPT Williams was able to intercede with the 
Admiral of NMPC-4 and his fellow department heads and get 
full user participation for a second systems stress test. 

Individual module testing was done by the 
contractors. When the new project manager for the 
contractor, V. Hammer, came on-board, her first concern was 
for the lack of interface (an aspect of integrative testing) 
testing between OAIS and its interfacing systems. Interface 
testing became one of her priorities. The interface which 
she had no control over was the Order Production Module 
(0PM)-OAIS interface. The 0PM was still under development 
at the time of interface testing. This status concerned 
both V. Hammer and LT Hopkins. Each took the matter to 
their immediate boss, but to no avail. 

Validation testing utilizing the test plans 
and OAIS user representatives was scheduled for the six 
weeks prior to implementation. Validation testing was 
conducted every afternoon for these six weeks. Problems 
detected were prioritized either for correction prior to 
implementation or after implementation. The contractor had 
only the morning hours before each testing session to work 
on corrections to the problems. One of the problems 
identified with new system implementation is having 
inadequate time to test [Ref. 13;p. 123]. This was 
definitely the situation with the OAIS implementation. All 
the personnel involved with the testing, contractors, LT 
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Hopkins, LT Perkins, and CDR Hazel did not think OAIS was 
ready for implementation. There were too many problems 
which needed to be fixed prior to implementation in addition 
to the lack of testing of the OAIS interface with the 0PM. 

During the OAIS validation testing, more 
emphasis and personnel were added to the 0PM project on both 
the Navy and contractor teams. The addition of extra people 
to a project has been shown to decrease productivity for a 
short time. The decreased productivity is due to time 
needed to train personnel, familiarize them with the project 
and the increased amount c time spent on communication 
between project members. 

(3) Training . Training of users and operators 
of the computer systems is also an important part of pre¬ 
implementation. Training for the users was increased over 
the last implementation try. Users were kept informed of 
changes to OAIS by way of OAIS User Bulletins and their user 
representatives. An updated OAIS U- r Manual was 
distributed. The user representatives were the users that 
participated in the validation test Through their 
exposure to the new system, they would be able to assist 
other users in their departments. The OAIS Help Desk 
personnel also were trained by having access to the test 
system in the early morning hours before the contractors 
used it to correct the software problems discovered in the 
validation testing. Full scale, "hands-on" training of 
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users did not take place due to non-availability of the test 
application during normal working hours. 

Operator training was planned to occur by 
having contractor personnel in Scheduling every night during 
the first few weeks of the new implementation. This would 
familiarize Scheduling personnel with the new procedures and 
potential problems. 

(4) Method of Conversion . There are four 
methods by which an organization can convert to a new 
computer system: direct cutover, parallel conversion, 
staged conversion and pilot system. Direct cutover is when 
conversion takes place all at once. The old system is 
terminated and the new one is put in operation immediately. 
Direct cutover was the method chosen in the May 1986 OAIS 
implementation. There are risks to this method. The 
primary one being that if a major problem is discovered with 
the new system, it may cause some computer downtime for the 
organization. Advantages to this method include a lack of 
transition costs, and psychologically, users may try harder 
to work with the new application when there is nothing for 
them to fall back on. Transition costs are those costs in 
resources (personnel, computer time) incurred from running 
two systems at the same time. [Ref. 11:p. 737] 

With parallel conversion, both the new and 
old systems are operated in parallel. The advantages to 
this method are that the old system is there to rely on in 
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case problems do develop with the new system. Disadvantages 
include the additional costs in resources of running and 
updating two systems. Staged conversion is essentially the 
replacement of the old system with the new system in a 
gradual manner. The advantage to this method is having the 
new capabilities of the new version while still retaining 
the flexibility to cope with any problems. The last method 
is by use of a pilot system. The new version is implemented 
in only one division within the organization. This 
minimizes the risk to the entire organization and also 
provides lessons learned to facilitate implementation in 
other parts of the organization. [Ref. ll:p. 736] 

NMPC-47 chose parallel conversion for this 
implementation of OATS. They possessed the additional 
computing capacity and willingness to take on the additional 
costs of resources to maintain both the old and new 
versions. There were several reasons for their choice of 
parallel conversion. OAIS users had a significant amount of 
work already completed in OAIS which would have had to be 
redone in the new system. It was determined that this would 
be detrimental to user service and user confidence. Also, 
in light of the implementation problems in May 1986, there 
would be a system to fall back on without any system 
downtime for the users. To ensure that users did not 
continue to use the old system unless they had previous work 
in OAIS JK, several of the screens were disabled. 
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(5) Conclusions . NMPC-47 improved their pre¬ 
implementation planning and activities. More thorough 
testing procedures were established and followed, covering 
all four types of testing necessary to inspect all aspects 
of new software. Users were involved with the testing 
through the use of test plans. More training of both users 
and operators was conducted. The ultimate state for 
training would include "hands-on” training for all the 
users, but this was unavailable to NMPC-47 due to the time 
and computer resources needed by the contractors to fix 
trouble reports discovered during testing. The decision 
concerning parallel conversion versus the direct cutover 
method was also a more cautious decision taking into account 
user workload. The area of testing remained the one problem 
of the pre-implementation activities. Insufficient time was 
allotted for the testing and sucsequent fixing of trouble 
reports needing fixing prior to implementation. 

Additionally, problems still existed with the OAIS-OPM 
interface, which was the most crucial of all the OAIS 
interfaces because it was responsible for the output of the 
application. Insufficient concern was allotted to the 0PM 
program and when it did become critical, more people were 
added to the project, slowing down productivity. 
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F. CASE STUDY FIVE TEACHING NOTE 

1. Questions 

What caused the OAIS problems? 

What cnaiiges snouid have been planned? 

2. Case Summary 

This case describes the problems which occurred 
after the re-implementation of OAIS in May 1987. The 
majority of problems encountered were with the OAIS-Order 
Production Module (0PM) interface. Other problems 
associated with the new OAIS were accounting data problems, 
missing orders, incorrect orders and difficulties with the 
Communication Center. The 0PM took the place of AUTONOM. 
The software changes this move necessitated were planned 
for. The administrative changes, which primarily affected 
the production portion of the department, were not planned 
for. These changes dealt with maintenance of magnetic 
tapes, increased demand for the letter sorter machine and 
inadequate reports for tracking of orders. Top management 
of NMPC-47 and the contractors got heavily involved in 
solving the problems. 

3. Manor issues/Problems 

Interface problems. 

Lack of planning. 

Top Management involvement. 
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4. Case Analysis 

a. Interface Problems 

On the surface, the majority of the problems 
with OAIS can be blamed on the interface between OAIS and 
the 0PM. Problems with this interface were identified 
during execution of the test plan. The 0PM failed all its 
tests, but was implemented anyway. The 0PM was identified 
as a critical interface approximately three months before 
the implementation date. Neither the Navy nor the 
contractor project management team increased their effort 
until a few weeks before implementation. The additional 
personnel added to the project only slowed down 
productivity. This was due to the increased time needed to 
familiarize the personnel with the project and for 
communication among project members. 

Developing the 0PM was an accomplishment of the 
NMPC-47 long-term goal of being responsible for the entire 
order production process. The 0PM did not just produce 
officer orders. It was also responsible for all the jobs 
previously accomplished by AUTONOM. AUTONOM had been 
responsible for producing the MPN Financial Management 
System (MFS) tape sent to Navy Finance Center, Cleveland 
with the accounting data and cost of each set of orders. 
AUTONOM had generated reports that assisted in the tracking 
of orders. AUTONOM had also placed OAIS information in the 
proper format for Naval messages or letters. It is obvious 






from top management's decision to implement the 0PM, even 
though it had failed the test plan, that they were unaware 
of all the possible repercussions of implementing the 0PM. 

Considering the six causes of poor performance 
on projects that Russell Archibald has compiled (see Case 
Study Three Teaching Note), the overriding general cause of 
the OAIS problems was a lack of integrated planning and 
control. Again, as in the previous implementation effort in 
May 1986, the improperly introduced matrix structure for 
project development is the root of the problems encountered. 
The project officer focus as on the software changes in 
OAIS, not on the changes which would be required of the 
entire organization to use the new OAIS. An information 
system is not just software. It also includes hardware, 
procedures, people and an applicable organization structure. 
With a system like OAIS that has far-reaching effects both 
on other organizations and on which users are heavily 
dependent, additional planning is needed. Additional 
planning in the form of establishing an interface with the 
0PM project officer from an early s^age in the project and 
having an integrated project team consisting of development 
and production-oriented personnel was needed. These 
^asures would have helped to prevent some of the problems, 
b. Lack of Planning 

An integrated project team could possibly have 
foreseen the following production-oriented problems: order 
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tracking and accounting, output verification, liaison with 
the Communication Center and condition of the letter sorter 
machine. The capability of tracking and accounting of 
orders could have been built into the reports generated for 
the OAIS Help Desk. Personnel performing verification of 
0PM output could have been trained and the new job 
descriptions could have been viewed with anticipation. An 
increase in duties to include liaison with the Communication 
Center could have been an increase in responsibility and 
morale for personnel at the OAIS Help Desk. With some 
advance planning, a good working relationship could have 
beer established with the Communication Center prior to OAIS 
implementation. Having foreseen possible problems with the 
magnetic tapes, a standard run book procedure could have 
been established for Scheduling. A new letter sorter o-^ 
supplementary maintenance of the old one could have been 
arranged in advance. A contingency plan could have been 
developed to provide for breakdowns. 

NMPC-47 was faced with both computer-oriented 
problems and organization problems due to the implementation 
of OAIS. These problems were addressed and dealt with only 
in terms of expediency. The civil servants in N472 were 
delegated the job of verifying the orders that OAIS 
generated. This was an added burden for these personnel and 
decreased their morale. Since the letter sorter was down so 
often, enlisted personnel had to spend several hours a day 
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sorting letters by hand and preparing them for mailing. The 
job of liaison with the Communications Center was given to 
the OAIS Help Desk. If a problem was discovered with the 
daily magnetic tapes, the contractors had to be called to 
redo the tape or part of the tape. This took time away from 
fixing the software problems. 

A problem with OAIS that was not caused due to a 
lack of testing were the enhancements made to OAIS JK that 
were not a part of OAIS 1.7. These were changes made by the 
Applications Programming Shop. These changes were not 
documented in the application documentation. Having them 
missing from the new version was again an example of a lack 
of integrated planning and control, 
c. Top Management 

Top management of both NMPC-47 and the 
contractor got involved to solvo the crisis. Meetings were 
held three times a week with management and technical 
personnel. Top management assigned priorities and due dates 
for individual problems. LT Hcpkins was taken out of the 
OAIS project. LT Perkins and CDR Hazel took control of day- 
to-day activities and correction of OAIS and 0PM trouble 
reports. Top management became involved in the details of 
daily OAIS production and long range plans for correction of 
trouble reports. Their computer expertise contributed some 
much need direction to the OAIS project. This crisis paved 
the way for NMPC-47 management to realize that their 
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information systems did not exist in a vacuum. Information 
systems had become an integral part of the NMPC mission. 

G. CASE STUDY SIX TEACHING NOTE 

1. Questions 

How do you evaluate CAPT Hampton's changes? 

What are the signs of NMPC-47 maturity? 

- How would you deal with the new contractors? 

2. Case Summary 

This case study addresses the timeframe of May 1987 
through November 1987. NMPC-47 is slowly recovering from 
the problems generated by implementation of an inadequately 
tested application. The focus of the organization is on 
regaining user confidence and fixing production-oriented 
problems. A new contractor has just been awarded the 
maintenance contract for OAIS. A new department head makes 
changes in the organization structure and implements changes 
to administrative policies. The information systems 
organization and its users have matured. Users have an 
interest in daily activities and a vote on the priorities of 
application enhancements. A steering committee for NMPC-47 
is formed to ensure compatibility of future plans for NMPDS 
and resource sharing. NMPC-47 has acquired sufficient 
functional expertise and computer savvy to be directing 
computer systems management with the contractors in an 
assistant role. 
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3. Major Issues/Problems 

Integration of inforroation system into organization. 

Data is a resource. 

Maintenance. 

Documentation. 

Standards and Quality Assurance. 

User Responsibility. 

4. Case Analysis 

a. Nolan's Stages of Growrh 

NMPC-47's information systems and management are 
now in the beginning of the Data Resource Function stage, 
stage five. Characteristics of this stage exhibited by 
NMPC-47 are consideration of data as a resource, 
consideration of applications as valuable assets and 
integration of information systems into the organization. 
Also, managers are experienced in information systems and 
computing issues. [Ref. ll:p. 674] 

(1) Data is a Resource . The establishment of 
the Configuration Control Board (CCB) is an indicator that 
NMPC-47 views data as a resource. This board is composed of 
functional managers, top management, technical experts and 
staff personnel from within NMPC-47. The focus of the CCB 
is on planning for the future, ensuring compatibility of 
data and requirements for the four applications within NMPDS 
and resource sharing. The CCB reviews any changes, both 
short and long term, prior to implementation. 
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The fact that applications are viewed as 
valuable assets in themselves is supported by two factors. 
One is the emphasis and time given to maintenance of OAIS. 
Placing an emphasis on maintenance expresses an evolutionary 
attitude concerning the importance of the information 
systems. Maintenance is the gradual upgrading and 
implementing of user and technical-oriented changes. This 
gradual process provides for economies of scale and long 
term efficiencies versus letting the system get outdated and 
having the large expense of developing from scratch [Ref. 
20:p. 11]. "The updating of existing systems and 
capabilities, the balancing of stability with a degree of 
change can be an important measure of financial and 
operational success and of “he maturity of the organization 
itself." [Ref. 20:p. 10] 

In addition to maintenance, time is also 
needed to regain user confidence in OAIS. This confidence 
can be restored by a steady track record of implementing 
fixes to problems caused by the 0PM and fixes to problems, 
such as PRD inconsistencies, that have existed for some 
time. By allocating all six contractor personnel to 
maintaining OAIS, this goal is possible. Additionally, 
allowing for maintenance time gave the new contractors time 
to understand the processes and programs of the OAIS 
application. This education will help facilitate the 
implementation of enhancements in the future. This time for 
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education is essential considering the poor condition of 
OAIS documentation. There is a cost to this emphasis on 
maintenance and re-establishing user confidence and that is 
application enhancements. Top management realized that with 
a new contractor, poor documentation, disappointed users and 
an unsteady OAIS foundation that the chances of problems 
with new enhancements, such as the problems experienced with 
the activity file, are likely. The benefits of taking this 
extra time will pay off in the future when the development 
of future enhancements takes less time and resources. 

(2) Documenta ion . OAIS documentation had been 
of poor quality since the inception of the project in 1982. 
Problems caused by this poor quality of documentation had 
not been encountered previous to this time for several 
reasons. One, the same contractor that had developed the 
original documentation and program code, still had 
responsibility for the project. Two, the changes being made 
to OAIS were primarily centered aroc, i conversion of the 
software version and total redesign of certain interfaces 
such as the 0PM and orderwriting mt ule. With a new 
contractor taking over the OAIS project there was 
unfamiliarity with the functions of the application as well 
as with the code. Adequately maintained documentation could 
have assisted the new contractor, instead of causing them 
problems. 

Documentation of information processing can provide the 

following benefits; (1) content and format guide for 
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documentation of data processing procedures, policies, 
practices and requirements; (2) complete record of an 
information processing system from analysis through 
implementation and maintenance; (3) data for simplifying 
and facilitating either conversion to new or upgraded 
hardware and or software or adoption of a new application; 
(4) communication medium for transfer of information. 

[Ref. 24:p. 121] 

The new contractor's initial tasking was to 
correct all the problems with the OPM and production OAIS. 
This is where the documentation was needed, to try to 
understand the intent and content of the program. It became 
evident at this point that the documentation had also not 
been kept up-to-date. These problems with documentation, 
particularly the reporting and recordkeeping fall under the 
function of quality assurance. 

(3) Standards and Quality Assurance . The 
second factor illustrating the organizations's view of the 
application as a valuable resource is the emphasis on 
standards. Standards for documentation, operating 
procedures and programs have existed since the establishment 
of NMPC-47. Configuration Management was responsible for 
making and distributing the policy on standards for 
organization and contractor use. Prior to this time period, 
however, the organization emphasis was on development. The 
extra time was not taken to ensure adherence to standards in 
the rush to get an application to the users. Once there was 
time, the problem seemed too hard and there were other 
pressing matters. It was not until NMPC-47 and the new 
contractors themselves experienced problems with the non- 
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documented software, that standards became the answer to 
their problems. 

Standards are important for the following 
reasons: they are a basis of communications, so that all 

involved are talking the same language, they ensure 
compliance with policies and practices and they minimize the 
effects of changes [Ref. 24:p. 108]. Standards are a part 
of preventive management. Having a quality assurance 
function within the project structure in also preventive 
management. 

Quality assurance comprises a variety of tasks...: 

(1) application of technical methods, (2) conduct of 
formal technical reviews, (3) testing of software, (4) 
enforcement of standards, (5) control of change, (6) 
measurement, and (7) recordkeeping and reporting. [Ref. 

12:p. 438] 

Quality assurance is built into the 
functions of an information systems department by the 
establishment and documentation of control systems and 
procedures which are responsible for monitoring quality 
[Ref. 20:p. 151]. NMPC-47 implemented the quality assurance 
functions by having the OAIS Help Desk review and certify 
the work done by the contractor and by the adherence to 
standards. Prior to this period, the work of the contractor 
was not verified nor evaluated to ensure compliance with the 
standards. A change to production control procedures was 
implemented for quality assurance purposes. Production 
Control personnel were made responsible for reviewing the 
run books and program naming conventions to ensure their 
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feasibility and adherence to standards. This review was 
required prior to implementation. The review time added a 
few days onto the implementation of fixes, but in the long 
run would save time by having standardized procedures. 
NMPC-47 had a long way to go until quality assurance was a 
part of every application and program, but they have started 
a program to work towards that goal. 

Quality assurance and utilization of 
standards minimize the effects of change on the application. 
Change is inevitable in a computer system. Changes are 
needed to correct errors, incorporate user requests for 
enhancements and to take advantage of technology 
advancements [Ref. ll:p. 605]. By minimizing the effects of 
change, the quality of maintainability is enhanced. 
Maintainability is defined by Roger Pressman as the ease 
with which software can be understood, corrected, adapted, 
and/or enhanced [Ref. 12;p. 531]. The concept of 
maintainability supports the design ion of an application 
as a valuable resource and that maintenance is part of an 
evolutionary approach to information systems planning. 

(4) User Responsibility . The managers of NMPC- 
47 are now experienced veterans of information systems 
development and computing requirements. A lot of lessons 
were learned the hard way and at user expense, but the 
experience and lessons learned have been effective. This 
growth in expertise is evident in several ways: 
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establishment of the CCB, adherence to standards, use of 
requirements analysis for 0PM fixes, and establishing a 
quality assurance review for contractor fixes. Another way 
the experience is evident is making the user more 
responsible for OAIS. The requirements of training prior to 
issuance of a password and mandatory attendance at user 
meetings were designed to make the users the driving force 
behind OAIS. By requiring the training of all users, NMPC- 
47 built user confidence [Ref. 209:p. 54]. This user 
education covered all aspects of the application and with 
this knowledge comes a sense of ownership, confidence, 
responsibility and interest. 

b. Organization Changes 

When Captain Hampton reported on-board, he made 
several changes to the organization structure of NMPC-47. 

He further refined NMPC-47 so that its branches were in 
alignment with the three functions and two support functions 
suggested for an information systems department. These 
three functions are development, maintenance and production. 
The two support functions are administrative and technical. 

A discussion of these areas is in the Case Study Four 
Teaching Note. 

The customer support task within the technical 
support function was centralized further with the move of 
Order Support personnel in N472 to N471. The Information 
Systems Support branch, N471, now included all customer 
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oriented interfaces. The function of production control was 
broken out from under Systems Administration. This move was 
in recognition of its importance to the organization. With 
this change, problems which had existed for some time were 
able to reach top management. One of these problems 
involved report distribution and had brought on a Naval 
Audit investigation concerning wasted paper. Further, the 
lack of adherence to standards was brought out in the open 
and the CCB acted on this deficiency. An information 
systems policy and procedures branch was created. This 
branch contained portions of the technical and 
administrative support functions. Configuration Management 
and Data Administration were placed in this branch. This 
consolidation created a division responsible for controlling 
the assessing the applications in NMPDS and planning for 
their future. 

c. New Contractors 

NMPC-47 top management is impressed with the 
honesty and technically proficient explanations they receive 
from the new contractors, SYSCON. With the decision to put 
all six programmers to work fixing production problems, the 
active implementation of standards for configuration 
management and establishment of a quality assurance 
function, NMPC-47 is in an excellent position to ensure the 
quality of contractor work. Additionally, these efforts 
will assist in returning the OATS project back to its good 
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reputation with the users. By having the CCB performing its 
function of ensuring compatibility and resource sharing for 
NMPDS and the contractor being required to explain the 
reasons behind both short and long term fixes, NMPC-47 has 
taken steps to guard against the problems caused by total 
reliance on a contractor. 

There are two suggestions to ensure the 
continued viability of OAIS. One is that as the contractors 
progress through fixing production-oriented problems, NMPC- 
47 direct them and provide the time and money for updating 
the system documentation. This will assist with future 
implementation efforts and the move toward redesign of OAIS 
into a database oriented application. The second suggestion 
concerns project management. The OAIS project officer 
should acquire some functional expertise with OAIS and 
utilize an integrated project development team composed of 
production and maintenance technically proficient personnel 
for planning future development eff-.,-Os. 







V. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

1. Research Question One 

The conclusion, in regard to the first research 
question concerning what could have done to prevent the 
problems from occurring with OAIS, is still ambiguous. 
Prevention of problems like those experienced with OAIS can 
only occur through adherence to established standards and 
procedures for documentation, testing, and quality 
assurance. Following through with these activities 
throughout the life cycle of OAIS will facilitate the 
implementation of future changes and help ensure that the 
maintenance phase tasks are easier. This experience with 
OAIS and the subsequent analyses of this case study has 
assisted in the identification of possible causes of 
problems during information systems development. This 
knowledge will be of value in the future to help identify 
potential problem situations before they turn into full¬ 
blown problems- 

The possible causes of problems pertaining to OAIS 
development include the following: (1) acceptance of poor 
quality documentation; (2) implementation of the prototype; 
(3) failure to adhere to standards; (4) lack of testing; and 
(5) lack of quality assurance activities. The problems 


152 





caused by the acceptance of poor quality documentation and 
implementation of the prototype had been put in motion by 
actions taken at the beginning of the OAIS life cycle. 

Documentation is viewed by the majority of software 
developers as a peripheral activity. Yet, documentation is 
essential for the performance of maintenance activities in 
the future. The documentation received on the Officer 
Assignment Information System (OAIS) was of poor quality. 

In addition, the documentation suffered from a lack of 
updating as changes were made and maintenance activities 
performed. It was not until a new contract for OAIS 
maintenance was awarded in 1987 that the full effects of the 
poor quality of documentation were felt by NMPC-47. The 
contractors required extra time to understand the OAIS 
programs while trying to fix software trouble reports. This 
extra time took resources away from implementing user 
requested software enhancements. 

Implementation of the prototype has been documented 
as a dangerous problem when utilizing the prototyping 
development methodology. This problem has been noted 
particularly in situations where users are unhappy with 
their present system. This was the case with NMPC. 

Problems had existed with the assignment process -ince the 
late 1970*s. OAIS drastically improved the assignment 
process in comparison to the manual system. NMPC-47 yielded 
to user pressure and implemented the prototype. It is easy 
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to see why NMPC-47 made the decision to implement the 
prototype. Implementation of the prototype was a sensible 
public relations move. Users loved OAIS and the publicity 
OAIS received within the organization made those departments 
that were not on-line yet, want OAIS as soon as possible. 
This positive attitude would facilitate future 
implementation efforts. Additionally, as prototyping was on 
the leading edge of technology, there was little information 
concerning the pros and cons of prototype implementation to 
guide NMPC-47. 

By implementing the prototype, NMPC-47 also set 
themselves up for efficiency and maintenance problems in the 
future. The prototype is developed rapidly with concern 
only for the output, not how the output is generated. There 
exists the possibility of compromises and inefficiencies in 
the implementation of the inner workings of the prototype. 
Though not explicitly stated as reasons for the problems 
with the OAIS versions implemented in 1986 and 1987, the 
inefficiencies in the development of the original prototype 
played a significant role. 

2. Research Question Two 

A second research question addresses explanations 
for problems encountered in OAIS implementation efforts. In 
addition to the impact of the implementation of the 
prototype mentioned above, the underlying factor which 
contributed to the problems encountered with both of the 


154 





OAIS implementation efforts in May 1986 and May 1987 was the 
project management function. 

NMPC-47 managed application development with a 
project officer and a matrix structure for liaison between 
project management and functional management. The 
organization was not properly prepared to accept matrix 
management. Personnel must be educated and procedures and 
behaviors must be changed in order for the matrix to 
function properly. Most people are familiar with the "one 
person-one boss" tradition. Switching over to being 
responsible to two bosses, in this case a project manager 
and a functional manager, involves stress and uncertainty 
for the personnel concerned. The project management 
function worked successfully in the matrix structure during 
the initial development and deployment of OAIS. During this 
timeframe a production version of OAIS and involved 
functional management did not exist. For the implementation 
efforts in May 1986 and 1987, a production version of OAIS 
with approximately 330 users and functional management 
concerned for its continued operation did exist. This 
caused conflicts regarding the scheduling of manpower and 
computer resources. 

A contributing factor to the implementation problems 
was a lack of integrated planning and control by the project 
manager for implementation of the new version. The project 
manager for OAIS was inexperienced in the software 
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development field. Her inexperience combined with a lack of 
m.anagerial skills contributed to a lack of integrated 
planning and control. One manifestation of this lack of 
planning and control was a lack of testing prior to 
implementation. In 1986, there was no integration, 
validation nor systems test of the entire application. If 
these tests had been conducted prior to implementation, OAIS 
would not have been implemented. Another factor was a lack 
of planning for changes other than software changes caused 
by im>plementation of a new version of OAIS. In May 1987, 
NMPC-47 became responsible for the entire order production 
process, taking over responsibility for a variety of tasks 
dealing with verification and generation of output. These 
changes were not planned for and subsequently caused 
significant problems within the organization and among the 
users. 

B. LIMITATIONS OF THE STUDY 

This case study dealt with one organization within the 
U.S. government. NMPC is a Navy Headquarters command and 
the constraints under which it operates may not apply to a 
lower-echelon command. Additionally, the computer 
application was developed using a prototyping development 
methodology and a third generation software language. 

Factors and events deemed important usiiig this methodology 
and software language many not apply to another type of 
methodology and software language. A further limitation 
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concerns the distribution of the computer application. OAIS 
was developed and utilized in one geographic location for a 
centralized group of users. Computer applications developed 
for distribution to several commands and spread over several 
geographic locations may not encounter the problems and 
events stated in this case. 

Of particular note is the contrast between public (U.S. 
government) and private industry. The limitations imposed 
on the U.S. government in ■:lude budget restrictions, full and 
open competition (when applicable) and bureaucratic 
practices for the approval of change. These practices take 
excessive amounts of time Private industry does not 
function under the same type of limitations. If changes are 
required, they occur rapidly. If a particular product or 
company is preferred, private industry can choose it. The 
method or solution that a U.S. government agency may invoke 
is limited by the above-stated restrictions. The method to 
correct a situation such as that of NMPC may differ 
depending on whether it is a U.S. g vernment agency or 
private industry. 

C. FUTURE RESEARCH 

In addition to documenting a situation where the leading 
edge of technology was an issue, this case also dealt with 
implementation of the computer application and its 
associated decisions and problems. The Computer Systems 
Management curriculum includes education on software 
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development principles and practices. There is little 
emphasis on the implementation side of the computer 
application. A recommended area for future research is an 
analysis of the feasibility of including implementation- 
oriented material within the curriculum. 


D. RECOMMENDATIONS 

1. Redesign of OATS 

In accordance with the problems encountered with 

prior OAIS implementation efforts, the following 

recommendations are suggested for NMPC's redesign of OAIS: 

Ensure complete and up-to-date documentation is 
available on OAIS programs and interfaces. 

- Utilize development personnel and programmers who are 
experienced with the particular database package 
chosen. 

Plan for and follow through on extensive testing of all 
four types. Plan for testing and error correction to 
proceed at a normal workday (eight hours) pace of 
operations by allowing extra time for testing. 

Educate and train OAIS users thoroughly prior to 
implementation. Hands-on training is the most 
effective. If the users comprehend the changes being 
made, they will be more tolerant of any errors that may 
be detected once the application is implemented. 

Don't let the political pressures of a headquarters 
environment allow implementation of an application that 
is not ready. This short-term decision will only cause 
long-term problems and cost more in terms of resources 
in the long run. 

2. Case Studies 


Very few of the students who come to the Naval 
Postgraduate School have had any experience with development 
or implementation of computer applications. The basic 


158 




principles and procedures of software development are 
included in the curriculum. To a limited extent, some 
experience with software development is gained through 
experience with group projects. This experience is 
primarily in the field of microcomputer applications. 
Additional experience, whether real or the simulated 
experience of a case study, covering the areas of software 
development within the Department of Defense and in a 
mainframe/minicomputer environment are needed. This 
experience can assist students when they are confronted with 
a similar situation once they leave school. One of the 
primary figures, the project officer, in this case study was 
a Naval Postgraduate School graduate. To ensure that 
graduates of the Computer Systems Management curriculum do 
not make the same mistakes due to the lack of experience, 
there needs to be a stronger emphasis on change and 
implementation issues in Department of Defense 
organizations. 
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APPENDIX A 


OATS INTERFACES 


OAIS interfaces with eight external applications and one 
internal (N47-managed) application. The internal computer 
system is the On-Line Distribution Information System 
(GDIS). GDIS is a database system and uses a Model 204 Data 
Base Management System (DBMS). OAIS provides daily or 
weekly updates of the personnel, billet and activity files 
to GDIS. GDIS does not pass any data back to OAIS. 

The Officer Master File (OMF) is the primary repository 
of personnel data on all active-duty officers. The OMF is 
managed by NMPC-16. Every night an OMF change tape is run 
to update OAIS. Changes generated within OAIS during the 
day are provided via magnetic tape to update the OMF. 

Changes generated within OAIS include PRD changes, 
submarine/aviation pay changes, and order information. 

The orderwriting system used until May 1987 was AUTONOM. 
AUTONOM was managed by NMPC-16, In addition to producing 
the officer orders for distribution to the fleet either 
through message or letter, AUTONOM also interfaced with the 
Officer Master File and the MPN Financial Management System 
(MFS). 

When AUTONOM was run, it was sorted against the Officer 
Master File which verified order number, order modification 
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number, and detaching UIC information between OAIS and the 
OMF. If what was on OAIS did not correspond with the data 
on the OMF, the order became an AUTONOM Reject. Whether the 
orders were generated or rejected, AUTONOM provided OAIS 
with a transaction tape on a daily basis. This tape was 
used to update order status information with the date 
transmitted in the case of order generation, or in the case 
of order rejection, to pass the orders back up the automated 
chop chain for further work. 

The MPN Financial Management System (MFS) tape was 
generated during AUTONOM processing. The MFS tape contained 
projected order costs for training and travel by individual 
SSN. This tape was sent to Naval Finance Center Cleveland 
on a daily basis by NMPC-16 and hard copy was provided to 
NMPC-7 for verification. 

The Order Production Module (0PM) took the place of 
AUTONOM in May 1987. The 0PM was managed by NMPC-47 through 
the Scheduling Shop. The 0PM was originally designed for 
use with the Enlisted Assignment Information System, but was 
used with OAIS when a common order format was agreed upon 
between officer and enlisted distribution communities. 

The Navy Manpower Data Accounting System (NMDAS) is 
managed by OP-01. Information concerning organizational 
manning totals, personnel and billet authorizations, and 
billet phasing dates is contained within NMDAS. Weekly 
changes to the database were provided via magnetic tape to 
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OAIS. These changes were of significant importance in 
assigning officers. 

The Officer Fitness Report File (FITREP) is the 
responsibility of NMPC-3 and operated by NMPC-16. Condensed 
statistical fitness report information by individual Social 
Security Number (SSN) is contained in this system. Twice a 
month, updates from this system were provided to OAIS. 

The Automated Detailing Instruction System (ADIS) was 
managed by NMPC-16. This system contained orderwriting and 
specific detailing instructions for each Navy activity. 

This information was updated in OAIS via magnetic tape twice 
a month. 

The Activity File was managed by the Enlisted Personnel 
Management Center (EPMAC). Information such as accountable 
Personnel Support Detachment Activities, Ship Deployment 
Dates, Command phone numbers and addresses were provided for 
each Naval activity. This information was updated once a 
month before May 1987 and once a week after May 1987. 

The Officer Candidate Accounting and Reporting System 
(OCARS) was managed by NMPC-16. OCARS contained information 
on Officer Candidates which was needed for initiating their 
first set of orders. Information contained in this system 
was obtained from the Naval Recruiting Command or the U.S. 
Naval Academy. This information was updated in OAIS via 
magnetic tape once a month. 
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The Navy Information Training System (NITRAS) was the 
responsibility of the Chief of Naval Education and Training 
(CNET). Information pertaining to course schedules, 
convening dates and course quotas was contained on this 
system. Updates were provided to OAIS on a weekly basis. 
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APPENDIX B 


TIMELINES AND PERSONNEL LISTS 


List of Personnel 

October 19 8 5 - May 1986 


NaiT.G 

Position 

Capt Williams 

N-47 Department Head 

Cdr Rice 

N-470 Branch Head 

Cdr Zeke 

Previous OAIS Project Officer 

Cdr Cinder 

Previous N-471 Branch Head 

Cdr Griffin 

N-471 Branch Head 

Cdr Hazel 

Previous Training Officer 
N-472 Branch Head 

Lt Hopkins 

OAIS Project Officer 

Mr Smith 

Technical Director 

Lt Perkins 

Training Officer 

Lt Smith 

Error Research 

DPI Brown 

Application Programming 


Figure 7. List of Personnel, October 1985-May 1986 


164 




List 

of Personne 

May 86 - May 87 

Name 

Position 

Capt Williams 

N-47 Department Head 

Cdr Rice 

N-470 Branch Head 

Lcdr V/all 

New N-470 Branch Head 

Cdr Griffin 

N-471 Branch Head 

Cdr Hazel 

N-472 Branch Head 

Lt Hopkins 

OAlS Project Officer 

Mr Smith 

Technical Director 

Lt Perkins 

Training Officer 

OAlS Help Desk 

V. Hammer 

Sage Project Officer 


Figure 8. List of Personnel, May 1986-May 1987 
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List 

of Personnel 

September 1987 

Name 

Position 

Capl Hampton 

N47 Departi' ent Head 

Lcdr Wall 

N470 Branch Head 

Car Griffin 

N471 Branch Head 

Car Haze! 

!t4^2 Branch Head/0PM 

Mr, Smitn 

Tecnnical Directcr 

Lt Sandem 

OAiS Project Officer/Dev 

it Perkins 

0AI5 Help Desk 

Training 

OAIS Proiect Officer/Prod 

Ms. Green 

SYS CON Project Manage^ 


Figure 9. List of Personnel, September 1987 
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Timeline May 86 - August 86 


av June July Au 


• 0AI5 1 7 , Contract Change 

• OAiS Help Dest Concept 

irTipiemente'd 


» No U5N Programming 

. ^ 1 ■* ^ “ 

• Training Move 

Faiiu'A 

. SAGE Tears Oa;S acart ^ 

• Finger Pomting 

• LT Hoplcins directives 


Breakdown into modules 


Test Plans 


Figure 10. Timeline for May 1986-August 1986 
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Timeline Sept 86 - Dec 85 


ept 

Oct 

Nov 

Dec' 

■ He!p Desk 

, NMPDS Dial- 

• RACF Security 

■ Caoability 

P-:ce Log 

Up Capability 

• Develop CAI5 

write PAD 
Resig Orcer; 

• SAGE re q jest 
F u " c t io n a i 

• c-A pert Users 

Test Plans 

• U S N n e V 1S W Si 

Expert 


• Software 
Conversion 

Test Pi.ans 

■ CDR Haze^ 

ce5;g'3tec! 

Functional 

E > p e r t 


Problem 

• Announcement 

OAIS 1,7 
available 

Marcn 1S37 

• CD’S 

Enhancement 


Figure 11. Timeline for September 1986-December 1986 
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Timeiine Jan 87 - April 87 


Fet) 

March 


Apri! 

, Project 

• Full Proluclion 

, OAIS ■ 

! 7 

at SAG E 

Control in N471 

Testing 
w itn 


• C7.anpe to 

• Annou^icement 

Test ria 

ns arc 

C c ' lOn P 

May vice March 
for OAIS 1.7 

Users 


• System Stress 
Tests 1 & 2 

irr.plementation 




, Capability write 
Retirement Orders 




Figure 12. Timeline for Jan ary 1987-April 1987 
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Timeiine Mav 
✓ 

87 - August 87 

vlay 

June 

July 

August 





. OAIS 1.7 

. Ll Hopkins 

• SAGE lost 

• Official turnover 

implemented 

Pack from 

contract to 

of OAIS/EAIS 


leave 

SYSCON 

to SYSCON 

• Crisis 
Management 


• Notification 

• New Project 



of Naval 

Officer for 

• Ouick/Dirly 


Audit 

OAIS Develop 

Fixes 



. Split contractor 

. Lt Perkins 



resources between 

and Cdr Hazel 



Production 

appointed 

OAIS Project 
officers 



and Development 


Figure 13. Timeline for May 1987-August 1987 
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Timeline Sept 87 - Nov 87 


Sept Oct Nov Dec 


• Capt Hampton 

• Policy of USN 

• New 472 Mission 

relieves 

personnel testing 


Capt Williams 

software fixes 

• Data Admin and 

* Activity File 

• CCB established 

Conf Mgt moved 
to 4 72 

Problem 

• User Reps 

• Requirement 

• OAIS 

vote on 

Analysis on 

Cevelopme nt 

priority of 

0PM SIR'S 

on hold 

STR/SCP 


• Prioritization 

• Training mandatory 

• Report Problems 

of SIR'S 


• Standards for 


• Order Support 

Run Books 

• OAIS User 

moved to 471 

and Naming 

Meetings 


Conventions 

Mandatory 

• Scheduling moved 



Figure 14. Timeline for September 1987-December 1987 
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